What DNS Does

Every device connected to the internet is identified by a numerical IP address — something like 93.184.216.34 for IPv4 or 2606:2800:0220:0001:0248:1893:25c8:1946 for IPv6. These addresses are how routers and network hardware actually locate machines on the internet. But humans do not think in numbers. We think in names.

The Domain Name System (DNS) bridges that gap. It is a globally distributed database that maps human-readable domain names like example.com to their corresponding IP addresses. When you type a URL into your browser, DNS is the first system that gets involved — before a single byte of HTML is transferred, your device needs to know the IP address of the server hosting that domain.

DNS was introduced in 1983 by Paul Mockapetris (RFC 882 and RFC 883, later superseded by RFC 1034 and RFC 1035). Before DNS, every networked computer maintained a local hosts.txt file that mapped hostnames to addresses. As the internet grew, maintaining that file by hand became impossible. DNS replaced it with a hierarchical, decentralized system that scales to billions of devices.

The DNS Resolution Chain

When you enter www.example.com into your browser, the resolution process involves multiple layers of caching and several types of DNS servers. Here is the full chain, in order:

  1. Browser cache: Your browser checks its own internal DNS cache first. Chrome, Firefox, and other browsers maintain a short-lived cache of recent lookups. If you visited the same domain a few minutes ago, the answer is already here and no network request is needed.
  2. Operating system cache: If the browser cache misses, the request goes to the OS-level resolver. On most systems, this is a stub resolver that checks the local DNS cache (managed by services like systemd-resolved on Linux or the DNS Client service on Windows). The OS also checks the /etc/hosts file (or C:\Windows\System32\drivers\etc\hosts on Windows) for hardcoded entries.
  3. Recursive resolver: If the OS cache also misses, the query is sent to a recursive resolver — usually operated by your ISP, or a public resolver like Google (8.8.8.8), Cloudflare (1.1.1.1), or Quad9 (9.9.9.9). The recursive resolver is the workhorse of DNS. If it does not have the answer cached, it performs the iterative lookup described in the next steps.
  4. Root name servers: The recursive resolver starts by querying one of the 13 root name server clusters (labeled A through M). The root server does not know the IP address of www.example.com, but it knows which servers are authoritative for the .com TLD and returns a referral to those servers.
  5. TLD name servers: The recursive resolver follows the referral and queries a .com TLD server. The TLD server does not know the final answer either, but it knows which name servers are authoritative for example.com and returns another referral.
  6. Authoritative name server: Finally, the recursive resolver queries the authoritative name server for example.com. This server holds the actual DNS records for the domain and returns the definitive answer — for example, that www.example.com has an A record pointing to 93.184.216.34.

The recursive resolver caches the result based on the record's TTL (Time to Live) value, so the next query for the same domain can be answered instantly without repeating the full chain. In practice, most DNS lookups are served from cache and resolve in under 10 milliseconds.

DNS Record Types Explained

DNS supports many record types, each serving a different purpose. Here are the ones you will encounter most often:

Type Purpose Example Value
A Maps a domain to an IPv4 address 93.184.216.34
AAAA Maps a domain to an IPv6 address 2606:2800:220:1:248:1893:25c8:1946
CNAME Alias — points one domain name to another www.example.com → example.com
MX Directs email to a mail server, with priority 10 mail.example.com
TXT Arbitrary text — used for SPF, DKIM, verification "v=spf1 include:_spf.google.com ~all"
NS Specifies the authoritative name servers for a zone ns1.example.com
SOA Start of Authority — zone metadata (serial, refresh, retry, expire) ns1.example.com admin.example.com 2024010101 ...
CAA Specifies which Certificate Authorities may issue SSL certificates 0 issue "letsencrypt.org"

The A and AAAA records are the most fundamental — they are the records that ultimately provide the IP address your browser needs. CNAME records are extremely common for subdomains: rather than duplicating IP addresses, you point www to the root domain and let it follow the chain. Note that CNAME records cannot coexist with other record types at the same name, which is why you cannot place a CNAME at the zone apex (the bare domain) if you also have MX or TXT records there.

TXT Records and What They're Used For

TXT records were originally designed to hold arbitrary human-readable notes about a domain. Today, they are one of the most important record types because they serve as a general-purpose verification and policy mechanism. Here are the most common uses:

If you manage email for a domain, getting SPF, DKIM, and DMARC right is critical. Missing or misconfigured records are the number one reason emails end up in spam folders or get rejected entirely.

TTL — Time to Live

Every DNS record has a TTL value, expressed in seconds, that tells resolvers how long they can cache the record before they need to fetch a fresh copy from the authoritative server. TTL is a tradeoff between performance and flexibility.

High TTL values (e.g., 86400 seconds = 24 hours) reduce DNS query traffic and speed up resolution for repeat visitors, since the answer is served from cache. However, if you need to change the record, users will continue seeing the old value until their cached copy expires.

Low TTL values (e.g., 60 or 300 seconds) ensure changes take effect quickly, but increase DNS query volume and can slightly increase page load times for users whose cache has expired.

A common best practice before a planned migration (such as changing hosting providers or moving to a CDN) is to lower the TTL well in advance:

  1. Several days before the migration, reduce the TTL from its current value (often 3600 or 86400) down to 60 or 300 seconds.
  2. Wait for the old TTL period to pass, so all cached copies expire and resolvers fetch the new, low-TTL record.
  3. Make the DNS change (point the A record to the new server).
  4. Once the migration is confirmed stable, raise the TTL back to a higher value.

Typical TTL values you will see in the wild:

DNS Propagation

When people say "DNS propagation takes up to 48 hours," they are describing the time it takes for a DNS change to be reflected everywhere on the internet. But DNS does not actually "propagate" in the way a message spreads through a network. There is no push mechanism. What actually happens is that cached records expire at different times.

Suppose your domain's A record has a TTL of 86400 seconds (24 hours), and a recursive resolver cached that record 23 hours ago. That resolver will serve the old IP address for one more hour before its cache expires. But another resolver that cached the record just 5 minutes ago will continue serving the old address for almost 24 more hours. Since every resolver on the internet cached the record at a different time, the update appears to "propagate" gradually.

This is why lowering your TTL before a migration is so important. If your TTL is 300 seconds, every resolver worldwide will have the new value within 5 minutes of the change. If your TTL is 86400, it could take a full day.

Other factors that can slow apparent propagation:

DNS over HTTPS (DoH)

Traditional DNS queries are sent as plaintext over UDP port 53. This means that anyone who can observe your network traffic — your ISP, a coffee shop's Wi-Fi operator, or a malicious actor on the same network — can see every domain you look up. This is a significant privacy concern.

DNS over HTTPS (DoH), defined in RFC 8484, solves this by sending DNS queries inside standard HTTPS connections on port 443. From a network observer's perspective, DoH traffic looks identical to regular web browsing traffic, making it extremely difficult to monitor or block individual DNS queries.

Browser support: All major browsers now support DoH. Firefox enables it by default in many regions, using Cloudflare's resolver. Chrome, Edge, and Safari support DoH but typically use the system-configured resolver if it supports DoH, rather than overriding the user's choice.

How it works: Instead of sending a raw DNS packet to port 53, the client makes an HTTPS GET or POST request to a DoH endpoint like https://dns.cloudflare.com/dns-query or https://dns.google/dns-query. The DNS query and response are encoded in a binary wire format (or JSON, depending on the server) and transmitted over the encrypted HTTPS connection.

There is also DNS over TLS (DoT), defined in RFC 7858, which wraps DNS queries in TLS on a dedicated port (853). DoT is more common in operating-system-level resolvers, while DoH is more common in browsers. Both achieve the same goal of encrypting DNS traffic, but DoH has the advantage of being harder to block since it uses the standard HTTPS port.

Debugging DNS

DNS misconfigurations are among the most common causes of website and email outages. Here are the signs and tools you need to know:

Common misconfiguration symptoms:

Essential debugging tools:

# Query A records for a domain
dig example.com A

# Query a specific name server directly (bypasses cache)
dig @8.8.8.8 example.com A

# Trace the full resolution path from root to authoritative
dig +trace example.com

# Check MX records
dig example.com MX

# Check TXT records (SPF, DKIM, DMARC)
dig example.com TXT
dig _dmarc.example.com TXT

# Windows equivalent
nslookup example.com
nslookup -type=MX example.com

The dig +trace command is particularly powerful. It shows every step of the resolution chain — from root servers to TLD servers to authoritative servers — so you can pinpoint exactly where the breakdown occurs. If the authoritative server returns the correct answer but users are seeing an old IP, the issue is caching and you need to wait for TTL expiration.