I feel like at least half of my postings to this blog have been about DNSSEC (and for those of you uninterested in DNSSEC, I’m sorry). But one DNSSEC-related topic I haven’t brought up is the “last mile.”
In DNSSEC, the “last mile” refers to communications between the stub resolver and the recursive name server. The stub resolver is the piece of the Domain Name System that resides on nearly every computer and translates an application’s request for data (say the address of www.infoblox.com) into a DNS query, and then sends that query to one or more name servers. The recursive name server receives a resolver’s query, examines its cache for the answer, and if it doesn’t find the answer there, may need to send one or more queries to remote name servers.
DNSSEC does describe some signaling between the stub resolver and the recursive name server. In particular, stub resolvers can set the CD bit in a query. The CD (Checking Disabled) bit tells the recursive name server not to validate DNSSEC-signed data on behalf of the resolver, but to return the various DNSSEC resource record types, such as RRSIG and DNSKEY RRs, so that the resolver can perform the validation. (It’s also sometimes used when troubleshooting DNSSEC problems.)
But no common stub resolvers implement their own DNSSEC validation, so CD is rarely used.
If CD isn’t used, the recursive name server will signal to the stub resolver that it has validated DNSSEC-signed data using the AD, or “Authenticated Data,” bit. That’s all very well and good, but the problem is that most communication between stub resolvers and recursive name servers is itself unauthenticated. A hacker who saw a resolver send a query to a recursive name server for a domain name in a signed zone could spoof a response to that stub resolver containing bogus records, and simply assert that the answer had been validated by setting the AD bit.
In firewalled corporate environments, this may be less of a concern than for home users. A company’s firewall shouldn’t allow DNS responses from arbitrary Internet addresses to internal stub resolvers, so the spoofing would have to happen internally. But most Internet-connected home computers either aren’t protected with a firewall or use a firewall that permits responses from name servers on the Internet (because that’s where their ISP’s name servers are).
What’s needed is some sort of authentication for the channel between the stub resolver and the recursive name server–as lightweight as possible, naturally, for the sake of busy recursive name servers. TSIG would seem like an ideal choice: It’s lightweight, and provides both authentication and integrity checking. But TSIG requires configuration of a shared secret, so it suffers from a nasty key distribution problem. If your recursive name server handles hundreds or thousands of stub resolvers, you’d need to configure a shared secret with each of them.
Microsoft’s GSS-TSIG would seem to solve that problem, at least for Active Directory environments. GSS-TSIG uses shared secrets already stored in AD to bootstrap the negotiation of a shared session key. Resolvers that run on computers in an AD domain, then, could automatically determine a key to use when querying a name server in that domain, and could validate its responses with the same key. Yet, inexplicably, Microsoft recommends configuring IPSec between resolvers and their name servers instead.
What’s the answer to this problem? Lobby your vendor for a stub resolver that supports TSIG for queries and responses! Now if we could just come up with a catchy way to put that on a bumper sticker….
