In our last installment in this “DNS fundamentals” series, we will close out focusing on the DNS security and arguably the most complex topic: DNSSEC.
As more actors began to use the internet, malicious parties began to take advantage of its open nature. To ensure the fastest possible response, DNS uses UDP packets, rather than establishing a TCP connection. While there is a gain in speed, it is also easier to spoof the packet address. Additionally, resolvers historically used the rst response to come in. These features combined to establish an environment in which the DNS lacked security. If you are going to yourbank.com, you really want it to be the right location, right?
DNS Security Extensions (DNSSEC) provide a framework to establish the integrity of answers received from the DNS. It does this in a way compatible with caches, but offering a Chain of Trust within the DNS tree, with each parent providing a signed hash of a key to verify the delegated child’s key. The chain of trust starts at the very top with Root, then goes to the TLDs, and so on. Within a zone, the private Zone Signing Key (ZSK) signs each RRset for that zone, and publicly stores a Resource Record Digital Signature (RRSIG) record with each. This is combined with the public portion of the ZSK, held as a DNSKEY record which when all together allows a resolver to verify the record itself.
To verify the ZSK is valid, it itself is signed with a Key Signing Key (KSK) which creates a DNSKEY RRSIG. Of course, it needs a public DNSKEY again. But how do you verify the KSK in the first place? To prevent this from going on forever, DNSSEC uses that chain of trust mentioned earlier.
Rather than put the public KSK on the actual zone alongside the ZSK, it is hashed into a Delegation Signer (DS) record and provided to the parent of that domain. So the TLD hands out the DS records which you can use to verify the KSK which you then can use to verify the ZSK which can verify the record. Of course, the TLD must be verified, so it has a series of RRsets, ZSKs and KSKs up to Root, which itself is signed. Because you are now at the root of the tree, there is nowhere else to go.
Each resolver around the world is configured to point to an initial trust anchor of the public Root KSK. The private Root KSK is used to sign the Root RRSIG of the DNSKEY RRset. Because this signing process is so critical to the security of the DNS, no single individual, organization, or nation was trusted to perform the signing.
Instead the signing actually occurs in person, in an elaborate key signing ceremony. Interestingly, the KSK itself has stayed the same since it was first used in 2010. The KSK was supposed to be rolled over in October 2017, but has been postponed because there were indications that a “significant number” of resolvers are not ready. So stay tuned for 2018 updates.
But wait! There’s more! Another way in which malicious actors may spoof a zone is to pretend to have access to a host that doesn’t exist within a zone. In this scenario, the response will be the absence of a record, not an explicit declaration that the record doesn’t exist. This has been documented as a method for spoofing.
To combat this, NSEC records which point to the next valid host were created, thereby proving the lack of existence of anything in between. The problem there is that it becomes possible to walk the zone and know everything that does exist. While DNS is public information, and private information should not be published in the first place, this worried people enough to create NSEC3 records which change this into a hash. There is even a proposal for NSEC5, which likely works by wizardry and unicorn dust alone. As we’ve seen, DNSSEC isn’t easy.
Wrapping it up
Well, that about covers it. The goal of this blog series, was to provide the information you need to better understand how all these pieces fit together. I’m sure we could keep on going, but I hope we have provided some help here.
If you ever find yourself staring down a long block of DNS, give us a call, we love geeking out! If you’re twisted enough to want more reading, here is a list of all the DNS Requests for Comment (RFC) over at the Internet Systems Consortium (ISC) who write BIND, the most used DNS software on the internet. And frankly, if you love DNS enough to have come this far, perhaps you should visit our careers page and consider joining our team!