[Discuss] DNSSEC

[Edward Ned Harvey (blu)]

Just as a follow-on to the DNSSEC conversation in another thread -

When a client sends a query to a dns server, it includes the DO bit, which is one of the extension bits formerly undefined (I don't know what year) but formerly required to be 0.  If set to 0, then the client does not support DNSSEC, and the server must strip any signing information, if present, before responding to the client.  If DO is set to 1, the client is specifically asserting that it supports DNSSEC, and the server should include RRSIG records (if any) in the response.  This is easy to see, as follows:

dig @8.8.8.8 verisignlabs.com +nodnssec
or
dig @8.8.8.8 verisignlabs.com +dnssec

Please note, I specifically chose this query because (a) google's public dns server 8.8.8.8 is publicly available and started supporting DNSSEC in 2013, and (b) I had to search around a little bit to find a domain that publishes DNSSEC records.  There is a DNSSEC verification tool available at http://dnssec-debugger.verisignlabs.com/, and naturally, verisignlabs.com itself is signed.

When using +nodnssec, DO is set to 0, which is the current default in at least my version of dig, and the response (as verified by wireshark) does not include RRSIG.  When using +dnssec, DO is set to 1, and the response includes RRSIG, confirmed by wireshark.

If the client supports DNSSEC, regardless of whether or not the response included RRSIG, the client has more work to do.  The client must obtain the DS records, starting from the root servers and working down, to determine if the domain in question should be signed or not.  Additionally, if the conclusion is that the domain in question should be signed *and* it is signed, then the client needs to get another record (which I think is DNSKEY) from the designated DS server, in order to validate the signature.

The top level root servers were first signed in July of 2010, so it is henceforth safe to always assume the root servers will be signed.  There is some controversy about the root servers signatures being US-controlled.  I make no other comments.  Just the way it is.  <tangent> This may be hair-brained of me, but I see no reason that other countries and other organizations couldn't operate their own dns root servers with their own signatures, as long as (a) the client OSes accept those signatures, and (b) the DS records that actually get served are actually the same, regardless of which dns root server served it.  So if you don't trust the US, you query a server in the US, and one in Brazil and one in Russia, and one in China, and confirm that they all responded with the same information and they all signed it.</tangent>

The DS record is used to delegate signing of subdomains, similar to the NS record being used to delegate resolving queries for subdomains.  So any DNSSEC aware client is able to (a) assume the root servers are signed, and (b) traverse a chain of DS records from the root server, to determine whether or not a particular subdomain is supposed to be signed.

Note, the DNSSEC aware client is not required to ask the root server directly - It can ask whatever DNS server was assigned via DHCP, for the DS record of "example.com" and this response will be signed by the root servers and therefore verifiable at the client, provided that it hasn't been corrupted.  It is ok for the dns caching server to cache and redistribute this information.

Slight side-note:  Besides the usual TTL that controls the longevity of caching, signatures themselves have expiration dates.  So it's important for clients and servers to have reasonably accurate clocks, and it's important to renew keys and signatures before their expiration dates start to cut into the TTL period.

So I am convinced, in all of the above, that the solution as a whole provides good security, given the answers to a small number of assumptions:

The keys of all the domains must remain secure, and the crypto algorithms must remain secure, and no blatant flaws in the communications protocol etc.  Obviously.

I have one major concern, which I don't yet have an answer to, and haven't yet found a way to test:

What happens if the local DNS caching server is old and doesn't support DNSSEC?  What if the client has support for DNSSEC, sets DO=1, and the caching server is old and doesn't know anything about DNSSEC?  Hopefully an old dns server is able to dumbly relay information that it doesn't understand.

This is a very important question, because:

If the behavior of old dns caching servers is to strip information that it doesn't understand, it means you simply can't use DNSSEC, even if your client supports it, as long as you're connected to some dumb internet connection (which might be peoples' dumb linksys routers, old coffee shops, etc).  And then the OS manufacturers will be forced to choose how to handle that situation - the possible outcomes would be either (a) ok, let's just use the insecure information, which implies breaking security all over the place and introducing trivial attack vectors even on networks that include support for DNSSEC (because the client cannot distinguish between asserting DO=1 and then having a malicious relay strip the bit, strip the signature and corrupt the data, versus a non-malicious obsolete cache server stupidly stripping all that information just because of ignorance), or (b) refuse to use the internet, or (c) somehow get some other DNS server other than the DHCP assigned server, which means OS manufacturers hard-coding some list of DNS servers into their OS.   Of course, if the OS manufacturer chooses (a) then all of DNSSEC is broken, but they just might choose it anyway because the alternative is broken internet for users, or higher cost to manufacturers.