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.
