DNS: Domain Name System

What is DNS?

DNS (Domain Name System) is a hierarchical, distributed database that translates human-readable domain names like example.com into machine-readable IP addresses like 93.184.216.34. Without DNS, you would need to memorize numeric IP addresses for every website you visit. It is often called the "phonebook of the internet" because it maps names to numbers, just as a phonebook maps people's names to phone numbers.

DNS was created by Paul Mockapetris in 1983 and formalized in RFC 1034 and RFC 1035. Before DNS existed, a single file called HOSTS.TXT maintained by the Stanford Research Institute contained every hostname-to-address mapping on the entire internet. As the internet grew, this centralized approach became unmanageable. DNS replaced it with a distributed system that could scale to billions of records.

Every time you open a web page, send an email, or connect to an API, DNS is working behind the scenes. Your device performs dozens or even hundreds of DNS lookups per day. The system is designed for speed and resilience: DNS queries typically resolve in under 50 milliseconds, and the distributed architecture means no single point of failure can take the entire system offline.

How DNS Resolution Works

When you type a URL into your browser, a multi-step resolution process begins. The goal is to find the IP address associated with the domain name. DNS resolution involves two types of queries: recursive and iterative.

In a recursive query, the client asks a DNS resolver to do all the work. The resolver will chase down the answer by contacting other servers on your behalf, and it will not respond until it has the final answer (or an error). This is what your computer does when it contacts your ISP's DNS resolver.

In an iterative query, the server responds with the best answer it currently has, which may be a referral to another server. The asking server then follows the referral and queries the next server. Recursive resolvers use iterative queries when talking to root, TLD, and authoritative servers.

The full resolution chain works like this:

1. Browser cache: the browser checks if it has recently resolved this domain. If so, it uses the cached result immediately.
2. Operating system cache: if the browser cache misses, the OS checks its own DNS cache. On most systems, the stub resolver handles this step.
3. Recursive resolver: if both local caches miss, the query goes to a recursive resolver (typically provided by your ISP or a public resolver like 8.8.8.8 or 1.1.1.1). The resolver may have the answer cached from a previous lookup.
4. Root name servers: if the resolver has no cached answer, it queries one of the 13 root server clusters. The root server does not know the final IP address, but it knows which TLD servers are responsible for .com, .org, and other top-level domains.
5. TLD name servers: the resolver follows the referral to the appropriate TLD server. For example.com, this would be a .comTLD server. The TLD server responds with a referral to the domain's authoritative name server.
6. Authoritative name server: the resolver queries the authoritative server, which holds the actual DNS records for the domain. This server responds with the IP address, and the resolver caches the result and returns it to your device.

DNS Record Types

DNS records are the entries stored on authoritative name servers. Each record type serves a different purpose. When you query DNS, you specify which record type you want, and the server returns matching entries. Understanding these record types is essential for managing domains, configuring email, and troubleshooting connectivity issues.

DNS Caching and TTL

DNS caching is what makes the system fast. Rather than repeating the full resolution chain for every lookup, DNS responses are cached at multiple levels. This dramatically reduces query times and decreases load on authoritative servers.

Caching occurs at several points in the resolution chain:

• Browser cache: modern browsers maintain their own DNS cache. Chrome, Firefox, and Safari all store recent lookups for quick reuse. This cache typically persists for the duration of the browser session.
• Operating system cache: the OS maintains a system-wide DNS cache that serves all applications. On macOS this is handled by mDNSResponder, on Windows by the DNS Client service, and on Linux by systemd-resolved or nscd.
• Recursive resolver cache:your ISP or public resolver (like Google's 8.8.8.8 or Cloudflare's 1.1.1.1) caches results for all its users. A popular domain queried by one user will be instantly available for millions of others.

The TTL (Time To Live) value controls how long a record can be cached before it must be re-queried. TTL is set by the domain owner on the authoritative server and is expressed in seconds. When a resolver caches a record, it counts down the TTL. Once the TTL reaches zero, the cached entry expires and the resolver must fetch a fresh copy.

Choosing a TTL involves a trade-off between performance and freshness. A low TTL (such as 300 seconds, or 5 minutes) means changes propagate quickly, but it increases the number of queries hitting authoritative servers. A high TTL (such as 86,400 seconds, or 24 hours) provides excellent caching performance but means changes take longer to propagate. Common practices include using low TTLs for records that change frequently (like load-balanced services) and high TTLs for stable records (like name server delegations).

DNS Hierarchy

DNS is organized as an inverted tree structure with the root zone at the top. Each level of the hierarchy delegates authority to the level below it, creating a distributed chain of responsibility.

• Root zone: the root zone is managed by ICANN and served by 13 root server clusters, labeled A through M. Despite the name, there are not just 13 physical servers. Through anycast routing, there are over 1,700 root server instances distributed worldwide. Root servers answer queries by referring resolvers to the appropriate TLD servers.
• TLD servers: Top-Level Domain servers handle queries for domains under their jurisdiction. Generic TLDs include .com, .org, and .net. Country-code TLDs include .uk, .de, and .jp. Each TLD is operated by a designated registry. For example, Verisign operates the .com and .net TLDs.
• Authoritative servers: these are the servers that hold the actual DNS records for a domain. When you register a domain and configure its DNS, you are placing records on authoritative servers. These servers are the final stop in the delegation chain and provide definitive answers for queries about their zones.

The delegation chain works through NS (Name Server) records at each level. The root zone contains NS records pointing to TLD servers. TLD servers contain NS records pointing to each domain's authoritative servers. This chain of delegation allows DNS to scale to hundreds of millions of domains without any single server needing to know about all of them.

DNS Security: DNSSEC

DNS was designed in the early 1980s without any built-in security mechanisms. Queries and responses travel in plaintext, and there is no way to verify that a response actually came from the legitimate authoritative server. This makes DNS vulnerable to several types of attacks.

DNS spoofing(also called cache poisoning) occurs when an attacker injects forged DNS responses into a resolver's cache. If successful, the resolver will direct users to a malicious IP address instead of the legitimate server. This can be used for phishing, credential theft, or malware distribution.

DNSSEC (DNS Security Extensions) addresses this by adding cryptographic signatures to DNS records. When a zone is signed with DNSSEC, each record comes with a digital signature that resolvers can verify. The chain of trust starts at the root zone (which is signed by ICANN) and extends down through TLD servers to authoritative servers. If any signature fails to validate, the resolver rejects the response.

DNSSEC protects data integrity (ensuring records have not been tampered with) but does not encrypt DNS queries. For privacy protection, two newer protocols have emerged:

• DoH (DNS over HTTPS): wraps DNS queries inside encrypted HTTPS connections on port 443. This prevents eavesdropping and makes DNS traffic indistinguishable from regular web traffic. Major browsers including Chrome and Firefox support DoH natively.
• DoT (DNS over TLS): encrypts DNS queries using TLS on a dedicated port (853). Unlike DoH, DoT uses its own port, which makes it easier for network administrators to identify and manage DNS traffic separately from web traffic.

Common DNS Tools

Several command-line tools are available for querying and troubleshooting DNS. These are essential for debugging domain configuration issues and verifying DNS propagation.

• dig: the most powerful DNS lookup utility. It provides detailed output including the query, answer, authority, and additional sections of the DNS response. It is the preferred tool for DNS debugging on Linux and macOS.
• nslookup: an older, simpler DNS query tool available on all major operating systems. It provides basic lookup functionality and is often the first tool people learn.
• host: a streamlined DNS lookup tool that produces concise, easy-to-read output. It is useful for quick lookups when you do not need the full detail of dig.
• whois: while not strictly a DNS tool, whois queries domain registration databases to find information about domain ownership, registration dates, and name servers.

Here is an example of what a dig query looks like:

$ dig example.com A

; <<>> DiG 9.18.18 <<>> example.com A
;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            86400   IN      A       93.184.216.34

;; Query time: 23 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; MSG SIZE  rcvd: 56

The output shows the question that was asked, the answer (an A record pointing to 93.184.216.34 with a TTL of 86,400 seconds), the query time, and which DNS server provided the answer.

Common Use Cases for DNS

• Web browsing: every URL you visit requires at least one DNS lookup to resolve the domain name to an IP address. A single web page may trigger dozens of DNS queries for embedded resources, scripts, and APIs hosted on different domains.
• Email delivery:when you send an email, the sending mail server queries DNS for MX records to find the recipient's mail server. It also checks TXT records for SPF, DKIM, and DMARC policies that verify sender authenticity.
• Load balancing: DNS can distribute traffic across multiple servers by returning different IP addresses for the same domain. Round-robin DNS returns addresses in rotating order, while more advanced setups use weighted or health-checked responses.
• CDN routing: content delivery networks use geo-DNS to direct users to the closest server. When a user in Tokyo queries a CDN domain, DNS returns the IP of a nearby edge server rather than one across the globe.
• Service discovery: SRV records allow applications to discover services on the network without hardcoded addresses. This is commonly used in VoIP, chat systems, and microservice architectures.
• Domain verification: services like Google Workspace, Microsoft 365, and SSL certificate authorities use TXT records to verify domain ownership. You prove you control a domain by adding a specific TXT record to its DNS.

Frequently Asked Questions About DNS

Why does DNS use UDP instead of TCP?

DNS primarily uses UDP because DNS queries and responses are small enough to fit in a single datagram. UDP eliminates the overhead of TCP's three-way handshake, making lookups faster. A typical DNS query and response each fit within 512 bytes. However, DNS does use TCP for zone transfers between servers and for responses that exceed 512 bytes. Modern extensions like EDNS allow larger UDP responses (up to 4,096 bytes), reducing the need for TCP fallback.

What happens when DNS goes down?

When DNS is unavailable, devices cannot resolve domain names to IP addresses. Websites appear unreachable even though the actual servers are running fine. Cached records continue to work until their TTL expires. This is why major DNS outages (like the 2021 Cloudflare or 2016 Dyn incidents) can make large portions of the internet seem offline. To mitigate this risk, organizations typically configure multiple DNS providers and use long TTLs on critical records.

What is a DNS TTL?

TTL stands for Time To Live. It is a value (in seconds) attached to every DNS record that tells resolvers and caches how long they may store the record before they must request a fresh copy from the authoritative server. A TTL of 3600 means the record can be cached for one hour. Lower TTLs allow faster updates but generate more queries. Higher TTLs improve performance but delay propagation of changes.

What is the difference between authoritative and recursive DNS?

An authoritative DNS server holds the official records for a domain and provides definitive answers. A recursive DNS server (also called a resolver) does not hold records itself but performs the full lookup process on behalf of clients, querying root, TLD, and authoritative servers as needed. Your ISP or a public service like 8.8.8.8 operates recursive resolvers. Domain owners configure authoritative servers through their registrar or hosting provider.

What is DNS over HTTPS (DoH)?

DNS over HTTPS (DoH) encrypts DNS queries by sending them inside standard HTTPS connections on port 443. Traditional DNS sends queries in plaintext over UDP port 53, which allows anyone on the network path to see which domains you are looking up. DoH prevents this eavesdropping and also makes it harder for networks to block or filter DNS queries, since DoH traffic looks identical to regular HTTPS web traffic. Major browsers support DoH, and public resolvers like Cloudflare (1.1.1.1) and Google (8.8.8.8) offer DoH endpoints.

How many root DNS servers are there?

There are 13 root server identities, labeled A through M, each operated by a different organization. However, through anycast routing, these 13 identities are served by over 1,700 physical server instances distributed across the globe. Anycast allows multiple servers to share the same IP address, with network routing directing each query to the nearest instance. This design provides both redundancy and low latency for root zone queries.

Related Protocols

• UDP: the transport protocol used for most DNS queries, providing fast, connectionless delivery
• TCP: used for DNS zone transfers and large responses that exceed UDP size limits
• HTTP: the web protocol that relies on DNS for domain name resolution before every request
• SMTP: email delivery protocol that uses DNS MX records to locate mail servers