A brief description of how DNS works
Understanding Domain Name System Security Extensions (DNSSEC) helps to understand the Domain Name System (DNS).
The proper functioning of the Internet is critically dependent on the DNS. Every web page visited, every email sent, every picture retrieved from social media: all those interactions use the DNS to translate human-friendly domain names (such as icann.org) to the IP addresses (such as 192.0.43.7 and 2001:500:88:200::7) needed by servers, routers, and other network devices to route traffic across the Internet to the proper destination.
Using the Internet on any device starts with the DNS. For example, consider when a user enters a website name in a browser on their phone. The browser uses the stub resolver, part of the device’s operating system, to translate the website’s domain name into an Internet Protocol (IP) address. A stub resolver is an elementary DNS client that relays an application’s request for DNS data to a more complicated DNS client called a recursive resolver. Many network operators run recursive resolvers to handle DNS requests or queries sent by devices on their network. (Smaller operators and organizations sometimes use recursive resolvers on other networks, including recursive resolvers operated as a service for the public, such as Google Public DNS, OpenDNS, and Quad9.)
The recursive resolver tracks down, or resolves, the answer to the DNS query sent by the stub resolver. This resolution process requires the recursive resolver to send its own DNS queries, usually to multiple different authoritative name servers. The DNS data for every domain name is stored on an authoritative server somewhere on the Internet. DNS data for a domain is called a zone. Some organizations operate their name servers to publish their zones, but usually, organizations outsource this function to third parties. There are different types of organizations that host DNS zones on behalf of others, including registrars, registries, web hosting companies, and network server providers, to name a few.
DNS by itself is not secure
DNS was designed in the 1980s when the Internet was much smaller, and security was not a primary consideration in its design. As a result, when a recursive resolver sends a query to an authoritative name server, the resolver has no way to verify the authenticity of the response. The resolver can only check that a response appears to come from the same IP address where the resolver sent the original query. But relying on the source IP address of a response is not a robust authentication mechanism since the source IP address of a DNS response packet can be easily forged or spoofed. As DNS was originally designed, a resolver cannot easily detect a forged response to one of its queries. An attacker can easily masquerade as the authoritative server that a resolver initially queried by spoofing a response that appears to come from that authoritative server. In other words, an attacker can redirect a user to a potentially malicious site without the user realizing it.
Recursive resolvers cache the DNS data they receive from authoritative name servers to speed up the resolution process. Suppose a stub resolver asks for DNS data that the recursive resolver has in its cache. In that case, the recursive resolver can answer immediately without the delay introduced by first querying one or more authoritative servers. However, this reliance on caching has a downside: if an attacker sends a forged DNS response accepted by a recursive resolver, the attacker has poisoned the cache of the recursive resolver. The resolver will then return the fraudulent DNS data to other devices that query for it.
Consider what happens when a user visits their bank’s website as an example of the threat posed by a cache-poisoning attack. The user’s device queries its configured recursive name server for the bank website’s IP address. However, an attacker could have poisoned the resolver with an IP address that points not to the legitimate site but to a website created by the attacker. This fraudulent website impersonates the bank website and looks just the same. The unknowing user would enter their name and password, as usual. Unfortunately, the user has inadvertently provided their banking credentials to the attacker, who could then log in as that user at the legitimate bank website to transfer funds or take other unauthorized actions.
The DNS Security Extensions (DNSSEC)
Engineers in the Internet Engineering Task Force (IETF), the organization responsible for the DNS protocol standards, long realized the lack of stronger authentication in DNS was a problem. Work on a solution began in the 1990s; the result was the DNSSEC Security Extensions (DNSSEC).
DNSSEC strengthens authentication in DNS using digital signatures based on public key cryptography. With DNSSEC, it’s not DNS queries and responses themselves that are cryptographically signed, but rather the data owner signs DNS data itself.
Every DNS zone has a public/private key pair. The zone owner uses the zone’s private key to sign DNS data in the zone and generate digital signatures over that data. As the name “private key” implies, the zone owner keeps this essential material secret. However, the zone’s public key is published in the zone itself for anyone to retrieve. Any recursive resolver that looks up data in the zone also retrieves the zone’s public key, which it uses to validate the authenticity of the DNS data. The resolver confirms that the digital signature over the retrieved DNS data is valid. If so, the DNS data is legitimate and is returned to the user. If the signature does not validate, the resolver assumes an attack, discards the data, and returns an error to the user.
DNSSEC adds two critical features to the DNS protocol:
- Data origin authentication allows a resolver to cryptographically verify that the data it received came from the zone where it believes the data originated.
- Data integrity protection lets the resolver know that the data hasn’t been modified in transit since it was initially signed by the zone owner with the zone’s private key.
Trusting DNSSEC keys
Every zone publishes its public key, which a recursive resolver retrieves to validate data in the zone. But how can a resolver ensure that a zone’s public key is authentic? A zone’s public key is signed, just like the other data in the zone. However, the public key is not signed by the zone’s private key but by the parent zone’s private key. For example, the org zone signs the icann.org zone’s public key. Just as a DNS zone’s parent is responsible for publishing a child zone’s list of authoritative name servers, a zone’s parent is also responsible for vouching for the authenticity of its child zone’s public key. Every zone’s public key is signed by its parent zone, except for the root zone: it has no parent to sign its key.
Therefore, the root zone’s public key is an important starting point for validating DNS data. If a resolver trusts the root zone’s public key, it can trust the public keys of top-level zones signed by the root’s private key, such as the public key for the org zone. And because the resolver can trust the public key for the org zone, it can trust public keys signed by their respective private key, such as the public key for icann.org. (In actual practice, the parent zone doesn’t sign the child zone’s key directly–the actual mechanism is more complicated–but the effect is the same as if the parent had signed the child’s key.)
The sequence of cryptographic keys signing other cryptographic keys is called a chain of trust. The public key at the beginning of a chain of trust is called a trust anchor. A resolver has a list of trust anchors and public keys for different zones that the resolver trusts implicitly. Most resolvers are configured with just one trust anchor: the public key for the root zone. By trusting this key at the top of the DNS hierarchy, a resolve can build a chain of trust to any location in the DNS namespace as long as every zone in the path is signed.
Validating and Signing with DNSSEC
For the Internet to have widespread security, DNSSEC needs to be widely deployed. DNSSEC is not automatic: right now, it needs to be enabled explicitly by network operators at their recursive resolvers and domain name owners at their zone’s authoritative servers. The operators of resolvers and authoritative servers have different incentives to turn on DNSSEC for their systems. Still, when they do, more users are assured of getting authenticated answers to their DNS queries. Quite simply, a user can be assured that they will end up at their desired online destination.
Enabling DNSSEC validation in recursive resolvers is easy. Nearly all common resolvers have supported it for many years. Turning it on involves changing a few lines in the resolver’s configuration file. From that point forward, when a user asks the resolver for DNS information from signed zones and that data has been tampered with, the user will (purposely) get no data back. DNSSEC protects the user from getting insufficient data from a signed zone by detecting the attack and preventing the user from receiving the tampered data.
Signing zones with DNSSEC takes a few steps, but millions of zones sign their DNS information so that users of validating resolvers can be assured of getting good data. Almost all common, authoritative name server software supports signing zones, and many third-party DNS hosting providers also support DNSSEC. Usually, enabling DNSSEC for a zone with a hosting provider is relatively straightforward: often, it entails little more than clicking a check box.
For a zone owner to deploy DNSSEC by signing their zone’s data, that zone’s parent and its parent, all the way to the root zone, must also be signed for DNSSEC to be as effective as possible. A continuous chain of signed zones starting at the root zone allows a resolver to build a chain of trust from the root zone to validate data. For example, to effectively deploy DNSSEC in the icann.org zone, the org zone needs to be signed, as well as the root zone. Fortunately, the DNS root zone has been signed since 2010, and all TLDs and many TLDs are also signed.
There is one more step to complete DNSSEC deployment in a zone: the newly signed zone’s public key material needs to be sent to the zone’s parent. As described earlier, the parent zone signs the child zone’s public key and allows a chain of trust to be built from parent to child.
Today, the zone owner must usually manually communicate the zone’s public key material to the parent. In most cases, that communication happens through the zone owner’s registrar. Just as a zone owner interacts with its registrar to make other changes to a zone, such as a list of the zone’s authoritative name servers, the zone owner also interacts with the registrar to update the zone’s public key material. While this process is manual, recently developed protocols are expected to allow this process to be automated in the future.
The following steps for DNSSEC
As DNSSEC deployment grows, the DNS can become a foundation for other protocols that require a way to store data securely. New protocols that rely on DNSSEC have been developed and thus only work in signed zones. For example, DNS-based Authentication of Named Entities (DANE) allows the publication of Transport Layer Security (TLS) keys in zones for applications such as mail transport. DANE provides a way to verify the authenticity of public keys that do not rely on certificate authorities. New ways of adding privacy to DNS queries will also be able to use DANE in the future.
In 2018, ICANN changed the trust anchor for the DNS root for the first time. Many lessons were learned about DNSSEC during that process. Furthermore, many resolver operators became more aware of DNSSEC and turned on validation, and the world got to see more clearly how the entire DNSSEC system worked. In the coming years, ICANN hopes to see greater DNSSEC adoption by resolver operators and zone owners. This would mean more users everywhere could benefit from DNSSEC’s cryptographic solid assurance that they get authentic DNS answers to their queries.
