DNSSEC on Windows 7 DNS client

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.

Comments

• Anonymous
  January 01, 2003
  It's not up to the client to "want" security for certain domains and not for certain others.  It's up to the client to want it depending on whether or not the domain is signed to begin with.  What I mean by that is that a TLD (such as .se, for example) can be signed, but a subdomain like shyam.se need not be signed because I may own shyam.se and I may not care about DNSSEC.  In such a scenario, you as the client will have to live with the fact that there's a signed-to-unsigned delegation, and this behavior in the Windows name resolution policy allows for that. Islands of trusts and signed-to-unsigned delgations are going to be quite common for a few years until DNSSEC is very widely adopted.

• Anonymous
  January 01, 2003
  PingBack from http://blogs.techrepublic.com.com/10things/?p=488

• Anonymous
  January 31, 2009
  Setting AD is a better strategy for a stub resolver that is not going to perform validation itself.  This is covered in dnssec-bis-updates. 4.6.  Setting the AD bit on Replies   Section 3.2.3 of [RFC4035] describes under which conditions a   validating resolver should set or clear the AD bit in a response.  In   order to protect legacy stub resolvers and middleboxes, validating   resolvers SHOULD only set the AD bit when a response both meets the   conditions listed in RFC 4035, section 3.2.3, and the request   contained either a set DO bit or a set AD bit.   Note that the use of the AD bit in the query was previously   undefined.  This document defines it as a signal indicating that the   requester understands and is interested in the value of the AD bit in   the response.  This allows a requestor to indicate that it   understands the AD bit without also requesting DNSSEC data via the DO   bit. http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-08.txt

• Anonymous
  February 04, 2009
  i understood it all until the point of "signed-to-unsigned delegation". in what scenario would you not want security on subdomains? (obviously signed to unsigned delegation) but what does that actually mean? eg. real world example.

• Anonymous
  November 08, 2009
  The comment has been removed

• Anonymous
  January 18, 2010
  I'm not a microsoft fan boy, but do a little research.  http://www.rfc-archive.org/getrfc.php?rfc=3655

• Anonymous
  April 15, 2010
  Alex C - RFC 4033 obseletes 3655.