DNSSEC – What Is It and Why Is It Important?

Interested in learning about Domain Name System Security Extensions (DNSSEC)? Click the image below to explore our infographic, which describes what DNSSEC is and outlines the benefits of deploying DNSSEC.

A brief description of how DNS works

To understand Domain Name System Security Extensions (DNSSEC), it helps to have a basic understanding of 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 a 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 web site name in a browser on their phone. The browser uses the stub resolver, which is part of the device’s operating system, to begin the process of translating the web site’s domain name into an Internet Protocol (IP) address. A stub resolver is a very simple 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 name server somewhere on the Internet. DNS data for a domain is called a zone. Some organizations operate their own 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, network server providers, just 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 strong 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 originally 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. If a stub resolver asks for DNS data that the recursive resolver has in its cache, the recursive resolver can answer immediately without the delay introduced by first querying one or more authoritative servers. This reliance on caching has a downside, however: if an attacker sends a forged DNS response that is accepted by a recursive resolver, the attacker has poisoned the cache of the recursive resolver. The resolver will then proceed to return the fraudulent DNS data to other devices that query for it.

As an example of the threat posed by a cache-poisoning attack, consider what happens when a user visits their bank’s website. The user’s device queries its configured recursive name server for the bank web site’s IP address. But an attacker could have poisoned the resolver with an IP address that points not to the legitimate site but to a web site 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 its banking credentials to the attacker, who could then log in as that user at the legitimate bank web site 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 and 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 DNS data itself is signed by the owner of the data.

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, this key material is kept secret by the zone owner. The zone’s public key, however, 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 DNS data it retrieved 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.

Go to ICANN Website for more.