This is the first in a series of multi-part blogs on cryptography and the Domain Name System (DNS).
As one of the first Internet protocols, DNS emerged at a time when today’s global network was still just an experiment. Security was not a primary consideration at the time, and the design of DNS, like other parts of the Internet at the time, did not include cryptography.
Today, cryptography is part of almost all protocols, including DNS. And from a cryptographer’s perspective, as I described in my talk at the International Cryptographic Module Conference (ICMC20) last year, there is so much more to the story than just encryption.
Where it all began: DNSSEC
The first large-scale deployment of cryptography in DNS was not for confidentiality but for data integrity, via Domain Name System Security Extensions (DNSSEC), introduced in 2005.
The story begins with the usual event that occurs millions of times per second around the world: a client asks a DNS resolver for a query like “What is the IP address of example.com?” The resolver in this case responds: “The IP address of example.com is 188.8.131.52”. (It is the right answer.)
If the resolver does not already know the answer to the request, the process for finding the answer looks like this:
- With the minimization of qname, when the resolver receives this request, it begins by asking a related question to one of the 13 root servers in DNS, such as root servers A and J operated by Verisign: “Where is the name server?” for the top .com level domain (TLD)? “
- The root server returns the resolver to the .com TLD server.
- The resolver asks the TLD server: “Where is the second-level domain (SLD) name server example.com located?” “
- The TLD server then refers the resolver to the example.com server.
- Finally, the resolver asks the SLD server: “What is the IP address of example.com?” “And receives a response:” 184.108.40.206 “.
But how does the resolver know that the answer it ultimately receives is correct? The process defined by DNSSEC follows the same model of “delegation” from root to TLD to SLD that I described above.
This is because DNSSEC allows the resolver to verify that the response is correct by validating a chain of digital signatures, examining digital signatures at each level of the DNS hierarchy (or technically, at each “zone” of the delegation process). These digital signatures are generated using public key cryptography, a well understood process that involves encryption using key pairs, one public and one private.
In a typical DNSSEC deployment, there are two active public keys per zone: a Public Key Signing Key (KSK) and a Public Key Zone Signing Key (ZSK). (The reason for having two keys is that one key can be changed locally, without the other key being changed.)
Responses returned to the resolver include digital signatures generated either by the corresponding KSK private key or by the corresponding ZSK private key.
Using mathematical operations, the resolver verifies all digital signatures it receives in association with a given request. If valid, the resolver returns the “Digital Signature Validated” flag to the client that initiated the request.
Chains of trust
A convenient way to visualize the collection of digital signatures is a “chain of trust” from a “trust anchor” to the DNS record of interest, as shown in the figure above. The chain includes “chain links” at each level of the DNS hierarchy. Here’s how “chain links” work:
The KSK root public key is the “trust anchor”. This key is widely distributed in resolvers so that they can independently authenticate digital signatures on root zone records, and thus authenticate everything else in the chain.
The root zone chain links consist of three parts:
- The KSK root public key is published as a DNS record in the root zone. It must match the trust anchor.
- The ZSK root public key is also published as a DNS record. It is signed by the KSK root private key, thus linking the two keys together.
- The hash of the KSK TLD public key is published as a DNS record. It is signed by the ZSK root private key, further extending the chain.
The links in the TLD zone chain also consist of three parts:
- The KSK TLD public key is published as a DNS record; its hash must match the hash published in the root zone.
- The TLD ZSK public key is published as a DNS record, which is signed by the TLD KSK private key.
- The SLD KSK public key hash is published as a DNS record. It is signed by the TLD ZSK private key.
The links in the SLD zone chain again consist of three parts:
- The SLD KSK public key is published as a DNS record. Its hash, as expected, should match the hash published in the TLD zone.
- The SLD ZSK public key is published as a DNS record signed by the SLD KSK private key.
- A set of DNS records, the ultimate response to the query, are signed by the SLD ZSK private key.
A resolver (or any other person) can thus verify the signature on any set of DNS records given the chain of public keys leading to the trust anchor.
Note that this is a simplified view and that there are other details in practice. For example, the different KSK public keys are also signed by their own private KSKs, but I have omitted these signatures for brevity. The DNSViz tool provides a very nice interactive interface for browsing DNSSEC trust chains in detail, including the trust chain for example.com discussed here.
Updating the KSK root public key
The effort to update the KSK root public key, the aforementioned “trust anchor”, has been one of the difficult and successful projects of the DNS community over the past two years. This initiative, known as the “Root KSK Rollover”, was difficult because there was no easy way to determine if the resolvers had actually been updated to use the latest Root KSK. Remember that cryptography and security has been added rather than built into DNS. . Many resolvers had to be updated, each being managed independently.
The research paper “Roll, Roll, Roll your Root: A Comprehensive Analysis of the First Ever DNSSEC Root KSK Rollover” details the KSK root update process. The article, co-authored by Verisign researchers and external colleagues, received the Distinguished Article Award at the Internet Measurement Conference 2019.
I focused here on how a resolver validates correctness when the response to a query has a “positive” response, that is, when the DNS record exists. Verification of correctness when the answer does not to exist becomes even more interesting from the point of view of a cryptographer. I will cover this topic in my next post.