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.


DNSSEC validation

Last hop – IPsec

IPsec encryption level


Set DO bit; Expect server to validate

Secure last hop with IPsec

High encryption


Don’t set DO bit; don’t expect server to validate

Don’t secure last hop with IPsec



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 (7)

  1. 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.

  2. Mark Andrews says:

    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



  3. Cameronk says:

    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.

  4. Jay Momo says:

    Looks like Microsoft wants to choke out GNU/Linux and Apple OSX systems from the network.  There is not a chance that AD bit thing is standardized or publicly documented in any way.  So, only Microsoft-authorized clients can use your Microsoft DNS/DHCP server, thus preventing any users from using any sort of non-Microsoft clients.  Awesome.

  5. Alex C1 says:

    I’m not a microsoft fan boy, but do a little research.  http://www.rfc-archive.org/getrfc.php?rfc=3655

  6. Chris says:

    Alex C – RFC 4033 obseletes 3655.

Skip to main content