Port 53 : DNSSEC Windows 7

DNSSEC deployment guide (Beta) for Windows Server 2008 R2

sseshad — Sat, 14 Feb 2009 02:07:00 GMT

Check out the Windows Server 2008 R2 DNSSEC Deployment Guide here:

http://www.microsoft.com/downloads/details.aspx?FamilyID=7a005a14-f740-4689-8c43-9952b5c3d36f&DisplayLang=en

Please note that this is a Beta guide. Your feedback is most welcome!

DNSSEC also features in the "What's New in DNS in Windows 2008 R2 page": http://technet.microsoft.com/en-us/library/dd378952.aspx

DNSSEC on Windows 7 DNS client

sseshad — Tue, 11 Nov 2008 19:48:00 GMT

Wow, the response to Windows 7 so far has been fantastic! PDC and WinHEC are over, the world has had a chance to finally get a preview of what we’ve been working on for over a year, and it is immensely satisfying to see such positive feedback.

Now let’s start talking about the different pieces of DNSSEC in Windows 7. Let’s begin with the DNS client since I think it would be easier to digest to start off with.

So in my last blog post, I used a rather gory term to describe the DNS client in Windows 7. I said it is a “non-validating security-aware stub-resolver”. It may sound scary, but if you look at it carefully, it is rather self-explanatory. Still, let me help you understand this a bit better.

In a nutshell, what this means is that the DNS client will not perform DNSSEC validation on its own. The client relies on its configured DNS server to perform validation on its behalf. One positive side-effect of this is that Trust Anchors do not need to be configured on the clients, thus saving a big chunk of the deployment burden. It is however security-aware, so it will expect the configured DNS server to indicate results of the validation when returning the response. This is done so by setting the “AD” bit in the response. If the DNS server failed to validate successfully (indicated by the AD bit not being set in the response), the DNS client will fail the query.

The security-aware behavior of the client is not a binary on/off. It is a policy based mechanism whereby the “Name Resolution Policy Table” will tell the client on which domains it is to expect DNSSEC. Only for those domains will the DNS client set the DO bit in the query and expect the AD bit in the response. The Name Resolution Policy Table (or NRPT for short) is a table of settings and configuration which defines the DNS client’s behavior when sending out queries and tells it what to do when receiving responses. The NRPT contains settings that pertain to DNSSEC as well as another new Windows 7 technology known as Direct Access. I won’t go into Direct Access here though.

Let’s look at an example of the NRPT. Below are a couple of rules in the table. Note that I have simplified the table contents a little for illustration purposes.

Namespace	DNSSEC validation	Last hop – IPsec	IPsec encryption level
*.example.com	Set DO bit; Expect server to validate	Secure last hop with IPsec	High encryption
*.foo.example.com	Don’t set DO bit; don’t expect server to validate	Don’t secure last hop with IPsec	n/a

So, rule 1 (*.example.com) applies to the example.com domain and all its subdomains. If an application passes in a query such as www.example.com to the DNS client, that query will match this rule in the NRPT. The rule then says that the DNS client must set the DO bit when issuing the query and check for the AD bit in the response. The rule also says it must use IPsec when issuing this query to the DNS server. And that’s exactly what the DNS client will do in this case.

Rule 2 is what we’d call an “exception”. If you look at the namespaces for rule 1 and rule 2, foo.example.com is a subdomain of example.com, hence the rule for example.com would apply to queries for foo.example.com as well. However, because a more specific rule is present in the table, any query under *.foo.example.com will match rule 2 and not rule 1. Rule 2 says no DNSSEC, hence the DNS client won’t set the DO bit, won’t look for the AD bit in the response and won’t use IPsec either. (Note that the above is what you’d do when you have a signed-to-unsigned delegation).

And there you have it…that in a nutshell is the DNS client’s behavior with respect to IPsec.

DNSSEC in Windows 7

sseshad — Thu, 30 Oct 2008 22:25:00 GMT

I'm excited that I finally get to talk about what the DNS team has been working on for over a year. That's right - DNSSEC. It's in Windows, and it's on its way.

DNSSEC is a suite of security extensions to the DNS which provide origin authority, data intergity and authenticated denial of existance. Putting that in plain English, DNSSEC allows for a DNS zone to be cryptographically signed (which produces digital signatures), and provides a mechanism for validating the authenticity of the data received using these digital signatures. Validating resolvers and servers must be pre-configured with a Trust Anchor, using which a "chain of trust" will be established to the signed zone. Data from this signed zone can then be validated.

The new and improved DNSSEC RFCs were published in 2005, and since then DNSSEC has seen a steady growth in attention. However this year, things took a much more dramatic turn mainly because of the vulnerabilities that were revealed at BlackHat by researcher Dan Kaminsky. More and more people are showing interest in DNSSEC as a good solution to lock down their DNS infrastructures.

Well, the timing is just perfect. Windows Server 2008 R2 DNS server will offer support for DNSSEC as per these new RFCs. The DNS server is now capable of generating keys and signing DNS zones using a sign-tool that we are providing with the product. The server will also be able to host these signed zones either as a primary or secondary zone, or as an Active Directory-integrated zone. Once configured with a Trust Anchor, the server will be able to perform full validation of data obtained from other signed zones.

On the DNS client, we have implemented a non-validating security-aware stub resolver. Doesn't roll off the tongue very easily, does it [:)]? Breaking it down, all this means is that the DNS client relies on its local DNS server to perform DNSSEC validation and will check to make sure that the server has indeed done so.

Pre-Beta builds of Windows are already available to those who attened the Professional Developers's Conference in LA that ended today. I would strongly encourage those of you who do have Windows 7 to test out DNSSEC and tell us what you think about it.

Over the next few days, I will blog more about what is and isn't in the product, so stay tuned!