DNS Security Extensions, or DNSSEC for short, is something most people working with DNS have heard about. In fact, the first working documents in the IETF were posted in September 1994, and now almost 16 years later, the root zone has finally been signed. In fact, the root zone is being signed today, July 15, 2010. This marks the end of a process that started on the 27th of January, 2010, when the first key material was made available in the root zone.
But what does “signing the root zone” imply? And what is this DNSSEC anyway? Most people have heard about PKI or Public Key Infrastructure. It is a special kind of system using asymmetric keys — asymmetric because one party encrypts with one key and another party decrypts with the other in a key pair. What is special is that the public keys (or rather, a hash of them) are all signed with the key of a parent node in a strict hierarchy, except for the key that is in the root node. That key is where all trust is bootstrapped from, and that root key is known and trusted by anyone. Because of the strict hierarchy of signatures on the keys, it is possible to, from the trusted root key, derive trust with any other key in the hierarchy.
Many PKIs have been deployed in the world, and the most well known are the keys used for SSL or TLS, specifically when using it for web access, or to be more specific, when using it to secure the HTTP protocol. But all of the initiatives so far have had the problem that people have not had the ability to really select one root, but instead have had to choose from a list of many root keys. If you look in the list of trusted CAs in a web browser for example, you will see that it is a very long list. In order to secure one’s website it is necessary to utilize a certificate from this list of trusted CAs.
DNS has a key difference from PKIs: due to the hierarchal naming (and delegation of administration) we already agree on one and only one root, i.e. the root zone. In that root, we have Top Level Domains (TLDs), such as .com, .net and .se. Below the top level domains we have another level of domains, such as cisco.com, arin.net, and regeringen.se, etc.
DNSSEC is in fact comprised of a few different components. First of all, it involves digital signatures attached to the records in the DNS. This implies that one gets both normal DNS records and DNSSEC records when querying the DNS and also gets digital signatures one can use to verify authenticity of the response. Secondly, DNSSEC includes a mechanism for storing the public keys in the DNS itself. These two components together imply that one can not only use the keys in the PKI to verify the records, but also use the PKI and keys to secure the keys themselves.
The last and, of course, most important part of DNSSEC has to do with the ability to do the actual verification of the DNS records. To be able to do that in a convenient way, you must configure the resolver with the so-called trust anchors you want to use. Before today (July 15, 2010), some TLDs (out of which Sweden, .se, was the first TLD) have been signed, but you had to add trust anchors for each one of those TLDs explicitly. Today, when the root zone is signed, one and only one trust anchor is needed to calculate a chain of trust from the trust anchor to the signature of the record from which authenticity is to be calculated.
The implications are, of course, that all involved DNS servers must support these security extensions, perform more calculations, manage larger messages in the DNS protocol than the standard length of 512 bytes, etc. But the actual overall impact to date has been much less than what even optimistic people like myself had anticipated. That said, there will most likely be bumps along the road to full scale deployment of DNSSEC. A few examples include firewalls discarding DNS messages larger than 512 bytes, fragmented UDP packets that do not reach the destination (when the DNS message is larger than MTU) and various similar things.
But this is not the only change happening with DNS this year. We also see more and more use of IPv6, both as content within DNS (in the form of AAAA records) and as a transport protocol for the DNS protocol itself. There is much more to say about these changes to DNS that happen to be the most revolutionary group of changes since we started to use DNS in the middle of the 1980s.
Today, July 15, 2010, is the real launch day of DNSSEC.