The Domain Name System (DNS) helps users find their way around the Internet. Every computer on the Internet has a unique address called its “IP address” (Internet Protocol address). Because IP addresses (which are strings of numbers) are hard to remember, the DNS allows a familiar string of letters (the “domain name”) to be used instead. So rather than typing “192.0.34.163,” you can type “www.icann.org.”
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 providing their 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.
Today the zone owner usually needs to communicate the zone’s public key material to the parent manually. 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 the 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 currently manual, recently developed protocols are expected to allow this process to be automated in the future.
