Many stories begin with “In the good old days …” but were the old days always so good? In the case of DNS, the old days go back a long way. You can read more about DNS itself at DNS at the core of the Internet.
Back at the beginning, one could say times were simpler but also resource limitations were restrictive as well. Services had to work more efficiently due to resource limitations like processor power, storage or network bandwidth to name just a few. And DNS reflects those simpler but restricted times in its protocols and design.
The modern Internet is a very different place to back then and for DNS, which is still one of the core components the Internet relies on, things have changed too. DNS has become one of many attack vectors for modern internet crime. The simpler times have caught up and the DNS infrastructure had to adopt.
Different Problems, Different solutions
There are many different attacks that exploit the trusting and simple nature of DNS. While some are more concerned with privacy while surfing the Internet, others are more concerned about the authenticity of DNS records.
For this article let’s focus on the authenticity of DNS records. This is where DNSSEC comes in. It is designed to ensure the authenticity of DNS records, not privacy of internet users.
There are many arguments against DNSSEC pointing out that DNSSEC is useless to improve privacy when resolving DNS names. So lets make one thing clear from the beginning, DNSSEC is not improving privacy, but is still an important improvement to ensure the authenticity of DNS records.
The Goal of DNSSEC
DNSSEC is essentially an add-on to the existing DNS infrastructure. It introduces an additional information into the DNS system which allow the verification of DNS records authenticity. Verifying the authenticity allows to detect any modification of the DNS records between the authoritative DNS server and the client attempting to resolve the DNS names. This of course has nothing to do with enhancing privacy, but ensures all DNS records arrive unaltered.
Many services relay on DNS records delivering trusted information. This trust is delivered by DNSSEC. It introduces additional records into the DNS system. Those records allow to verify the DNS records cryptographically. Those specific DNSSEC records allow also to verify a chain of trust from the record up to the root of the DNS system.
The general Idea
DNSSEC provides a set of DNS records of a specific type as well as cryptographic keys and methods. The fundamental idea behind the chain of trust is similar to that of TLS certificates used for websites and other services.
While TLS uses many trusted root Certificate Authorities (CA’s), DNSSEC provides a set of root-DNS trusted keys. The public root-keys are well-known and the resolving DNS client knows them. With that trust anchor, top-level-domains (TLD), “net” as example, create their DNSSEC keys and let the root-zone sign those. This establishes trust from the root-zone’s key to the TLD-zone’s key. The next is the domain, Lets say “tinned-software.net”, which will create keys of their own and get them signed by the TLD’s keys. This way the chain of trust starts at the well-known root-zone key and propagates down to the TLD and the domain’s key. The domain’s keys are used then to sign the records themselves, like “blog.tinned-software.net” for example, finishing the chain of trust down to the A record returned in this example.
Good practice at this point suggests 2 keys for each root, TLD and domain. The reasoning is for security and practical reasons as I would summarize it. One key is used to build the trust to the parent zone, from TLD to root-zone, for example, and the second key, signed by the first, is used to sign the records themselves. With those records is then as well the key for the child zone like “tinned-software.net”.
The reasoning for the separation into two keys is as follows. The first key provides the trust to the parent zone. This key is more complicated to replace. The second signs the zone data and is only signed by the first key. To ensure the security of the second key it should be replaced relatively often. As this key is only signed by the first, replacing it is relatively easy and can even be automated. The first key is more complicated but as it is used less, doesn’t need replacing so often.
This allows the DNS server administrator to reduce the amount of manual or more complex tasks while still keeping the security standard high.
Principle of key management
As mentioned already, each zone is suggested to have 2 keys. It is technically also possible to use just one key, but good practice suggests 2 keys and I agree for reasons stated later.
Staying with the two key approach, those two keys are named KSK (Key-Signing-Key) and ZSK (Zone-Signing-Key). As the name suggests, the ZSK signs the zones DNS records or to be more precise, the zones Resource-Record-sets (RRs). Those signatures are also renewed in a certain interval. This results in a relatively large amount of signatures that are performed with that key. The KSK on the other hand has only one job of signing the ZSK keys (their key record in the zone). All those signatures will be renewed on a regular interval too.
With the signatures, the public information of the keys is published in the zone as well. This public key allows DNS resolvers to verify the signatures.
Security considerations suggest that if enough signatures to known text is available, the private key might be reconstructed. This is why the DNSSEC keys should be rotated. As the ZSK signs all the DNS data, and the KSK only very few records, the ZSK should be renewed more often then the KSK. Additionally, replacing the KSK is more effort as it involves replacing its record in the parent zone.
So, the ZSK needs to be replaced more often, but this replacement is also easier as it does not involve any other DNS server. On the other hand, the KSK can be used much longer before replacing it, but it is higher effort to replace as it involves the parent zone’s records. With this splitting of the keys’ responsibilities, the security standard is kept high without causing too much effort while replacing them.
Signed DNS records
With the keys in place, the ZSK is used to sign the actual DNS zone records. While at first glance, it seems every record is signed, it’s actually a set of records. A so called resource record set (RRs) is a set of DNS records that will always be delivered together. One example is the NS records for a zone. It is impossible to request just one of the NS records for a zone. All the NS records in this example will be signed together as they are always returned together, they are one RRs.
The signature for each RRs is added to the zone as a separate record. This record can be requested by DNSSEC supporting DNS resolvers to verify that the DNS records have not been modified from the authoritative DNS server to the resolver. While verifying, the resolver requests the RRs signature as well as the DNSSEC keys of the zone to verify it.
Finally, the resolver walks up the DNS hierarchy (if not cached already) and requests the DNSSEC keys public information and signatures. With that, the resolver is able to not only verify the validity of the signature but also the validity of the chain of trust from the well-known root keys down to the signature of the DNS records.
Summary
DNSSEC is an important part of the DNS system to ensure DNS records are not altered or modified by any unauthorized party. This is achieved using cryptographic signatures and a chain of trust.
As mentioned in the beginning, this is not a privacy feature and was never intended to be. It is a matter of authenticity and trust which is the basis of many security mechanisms. This trust is required for a number of DNS based or DNS-backed security features.
Read more of my posts on my blog at https://blog.tinned-software.net/.
