What is DNS?

What is DNS#

The Domain Name System (DNS) is a hierarchical, distributed naming system that maps human-readable domain names like example.com to machine-routable IP addresses like 93.184.216.34. It functions as the internet's directory service, nearly every network connection begins with a DNS query, making it one of the most critical pieces of internet infrastructure. Without DNS, users would need to memorize numerical addresses for every site they visit.

DNS organizes names into a tree structure. The root sits at the top, followed by top-level domains (TLDs) like .com or .uk, then second-level domains like example.com, and optionally further subdomains like www.example.com. Each level of the tree can be managed by a different organization, which is what makes the system scalable. This delegation model means no single server needs to know every domain, responsibility is distributed across millions of name servers worldwide.

How DNS resolution works step by step#

When a user types a domain into a browser, the query follows a chain of lookups involving multiple types of DNS servers:

1. Local cache check. The browser first checks its own DNS cache, then the operating system's stub resolver checks its local cache. If a valid cached answer exists (one whose TTL hasn't expired), the query is answered immediately without any network traffic.

2. Recursive resolver. On a cache miss, the stub resolver forwards the query to a configured recursive resolver (often provided by the ISP or a public service like 8.8.8.8 or 1.1.1.1). The recursive resolver is responsible for doing the heavy lifting of chasing down the answer.

3. Root name server query. The recursive resolver checks its own cache. If it doesn't have the answer, it queries one of the 13 root name server clusters (labeled A through M, operated by organizations like ICANN, Verisign, and USC-ISI). The root server doesn't know the final answer, it responds with a referral to the appropriate TLD servers (e.g., the .com servers).

4. TLD server query. The recursive resolver follows the referral and queries the TLD name server. For a .com domain, this is operated by Verisign. The TLD server responds with another referral, this time to the domain's authoritative name server.

5. Authoritative server query. The recursive resolver queries the domain's authoritative name server, which holds the actual DNS records for the zone. This server returns the final answer, for example, the A record containing the IP address.

6. Response returned. The recursive resolver caches the response and returns it to the stub resolver, which passes it to the application. The entire process typically completes in under 100 milliseconds.

This iterative process means the recursive resolver does the work on behalf of the client, following referrals from root to TLD to authoritative server. The client itself only communicates with the recursive resolver.

Types of DNS servers#

Understanding DNS requires distinguishing between the server roles involved:

Root name servers sit at the top of the hierarchy. There are 13 root server identities (A.root-servers.net through M.root-servers.net), but each is actually a cluster of hundreds of servers distributed globally via anycast. They handle referrals for every TLD.

TLD name servers are authoritative for top-level domains. The .com TLD servers know which name servers are authoritative for every .com domain but don't store the actual records for those domains.

Authoritative name servers hold the zone data for specific domains. When you configure DNS for example.com at a provider like Cloudflare or AWS Route 53, you're configuring the data served by that provider's authoritative name servers.

Recursive resolvers (also called caching resolvers) accept queries from end-user devices, walk the delegation chain, cache results, and return answers. ISPs operate recursive resolvers for their customers; public alternatives include Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1), and Quad9 (9.9.9.9). Some recursive resolvers also provide DNS filtering or protective DNS capabilities (resolver policies that block or sinkhole known-malicious names).

Stub resolvers are lightweight resolvers built into operating systems. They don't perform recursion, they simply forward queries to a configured recursive resolver and cache the results locally.

DNS caching and TTL#

Caching is fundamental to DNS performance. Without it, every network connection would require a full resolution chain from root to authoritative server, adding latency and generating enormous query volumes.

Every DNS record includes a TTL (Time to Live) value, set by the zone operator, that tells resolvers how long they may cache the response. A TTL of 3600 means the record can be reused for one hour before a fresh lookup is required. When the TTL expires, the resolver must query the authoritative server again.

TTL is a tradeoff:

• Short TTLs (60–300 seconds) enable fast failover and quick propagation of changes, but increase query volume on authoritative servers and add latency for users.
• Long TTLs (3600–86400 seconds) reduce query volume and improve performance, but delay the propagation of DNS changes. If you update an A record with a 24-hour TTL, some users may still reach the old IP for up to a day.

Caching happens at multiple layers, the recursive resolver, the operating system's stub resolver, and often the browser itself. Each layer respects the TTL independently, so the effective cache duration can vary by client.

Negative caching also matters. When a domain doesn't exist, the resolver caches the NXDOMAIN response according to the SOA record's minimum TTL field. This prevents repeated queries for non-existent names.

Transport (UDP and TCP)#

Most DNS queries use UDP on port 53 for speed, a typical query and response fit within a single packet. When a response exceeds 512 bytes (or 4096 bytes with EDNS0), or when the server sets the truncation (TC) flag, the client retries over TCP. Zone transfers between authoritative servers (AXFR/IXFR) always use TCP.

Newer encrypted transports add confidentiality to DNS queries. DNS over HTTPS (DoH) wraps queries in HTTPS on port 443, making them indistinguishable from web traffic. DNS over TLS (DoT) uses a dedicated port (853). Both prevent passive observation of queries but shift trust to the resolver operator. These protocols are covered in detail in the DNS security article.

Core record types#

DNS supports many record types, each serving a different purpose:

• A and AAAA records map a name to an IPv4 or IPv6 address
• CNAME records create an alias pointing one name to another
• MX records direct email to mail servers, with priority values
• TXT records hold arbitrary text, widely used for SPF, DKIM, and domain verification
• NS records delegate a zone to its authoritative name servers
• SOA records identify the primary server for a zone and define refresh parameters

Each record type has specific security implications, unexpected changes to NS or MX records, for example, can indicate a domain hijack. Signing records with DNSSEC adds cryptographic verification that responses haven't been tampered with during transit.

DNS and security#

DNS is foundational to internet connectivity, which also makes it a high-value target. Attacks like DNS cache poisoning inject forged responses into resolver caches, silently redirecting users. DNS tunneling encodes data within queries to bypass network controls. And because attackers who register lookalike domains must configure DNS records before their infrastructure works, monitoring DNS provides early detection opportunities, new A records, MX records, and name server changes on suspicious domains can signal threats before end users encounter them.