Understanding DNS: How Domain Names Resolve to IP Addresses

What Is DNS?

The Domain Name System (DNS) is the internet's phone book. Computers communicate using IP addresses — numerical labels like 104.21.45.32 — but humans prefer memorable names like example.com. DNS is the system that translates between the two.

Every time you type a domain into your browser, send an email, or load an app that connects to the internet, a DNS lookup happens behind the scenes. This lookup takes your human-readable domain name and returns the IP address of the server you need to reach. The entire process typically completes in under 50 milliseconds and is invisible to users.

DNS was designed in 1983 by Paul Mockapetris as a replacement for a single HOSTS.TXT file that was manually maintained and distributed — a system that couldn't scale to more than a few hundred computers. Today, DNS handles hundreds of billions of queries per day across a globally distributed hierarchy of servers.

DNS Hierarchy

DNS is organised as a hierarchical, distributed database. Think of it like a tree structure with different levels of authority:

Root Servers

At the top of the hierarchy are 13 root server clusters (labelled A through M), operated by various organisations including ICANN, VeriSign, NASA, and others. Despite being "13," there are actually hundreds of physical servers globally due to anycast routing — requests are automatically directed to the nearest instance. Root servers don't store domain records; they know which TLD servers to ask next.

TLD (Top-Level Domain) Servers

The root servers refer queries to TLD nameservers, which are responsible for specific domain extensions: .com, .org, .net, .uk, .de, etc. VeriSign operates the .com and .net TLD servers. TLD servers know which authoritative nameservers are responsible for each second-level domain (like example.com).

Authoritative Nameservers

Authoritative nameservers hold the actual DNS records for a domain. When you register a domain and set it up with a hosting provider, you configure your domain's authoritative nameservers — typically something like ns1.cloudflare.com or ns1.yourhostingprovider.com. These servers are the definitive source for your domain's records.

Recursive Resolvers

Most DNS queries are handled by a recursive resolver (also called a recursive nameserver or DNS recursor). This is typically operated by your ISP or a public DNS provider (like Cloudflare or Google). When your device needs to resolve a domain, it asks the recursive resolver, which does all the work of walking the DNS hierarchy on your behalf and returns the final answer.

DNS Record Types Explained

DNS zones contain various resource records (RRs), each with a specific type and purpose:

A Record (Address Record)

Maps a domain name to an IPv4 address. The most common record type — this is what your browser looks up when you type a URL.

example.com.    300    IN    A    93.184.216.34

AAAA Record (IPv6 Address Record)

Maps a domain name to an IPv6 address. Named "quad-A" because IPv6 is four times the bit width of IPv4.

example.com.    300    IN    AAAA    2606:2800:220:1:248:1893:25c8:1946

CNAME Record (Canonical Name)

Creates an alias from one domain name to another. Often used to point www.example.com to example.com, or to point a subdomain to a third-party service. A CNAME cannot coexist with other records for the same name (which is why you can't use a CNAME at the zone apex — the root domain itself).

www.example.com.    300    IN    CNAME    example.com.

MX Record (Mail Exchange)

Specifies the mail server responsible for accepting email for a domain. Includes a priority value — lower numbers are tried first, enabling mail server redundancy.

example.com.    300    IN    MX    10    mail.example.com.
example.com.    300    IN    MX    20    mail2.example.com.

NS Record (Name Server)

Delegates a DNS zone to a set of authoritative nameservers. These records are what TLD servers use to refer queries to your domain's nameservers.

example.com.    86400    IN    NS    ns1.exampledns.com.
example.com.    86400    IN    NS    ns2.exampledns.com.

TXT Record (Text Record)

Holds arbitrary text data. Widely used for domain verification (Google, Microsoft), SPF (specifying which servers can send email for your domain), DKIM (email signing keys), and DMARC (email authentication policy).

example.com.    300    IN    TXT    "v=spf1 include:_spf.google.com ~all"

PTR Record (Pointer Record)

The reverse of an A record — maps an IP address back to a domain name. Used for reverse DNS lookups, which mail servers use to verify sender legitimacy. PTR records live in a special zone called in-addr.arpa for IPv4 or ip6.arpa for IPv6. You can perform reverse lookups using the reverse DNS tool.

SOA Record (Start of Authority)

Every DNS zone has exactly one SOA record. It contains metadata about the zone: the primary nameserver, the email address of the zone administrator, the zone's serial number (used to track changes), and timing parameters for zone transfers and negative caching.

How DNS Resolution Works (Step by Step)

Let's trace what happens when you type www.example.com into your browser for the first time:

1. Local cache check: Your operating system first checks its local DNS cache. If you've visited this domain recently, the answer may already be stored and no query is needed.
2. Query the recursive resolver: If not cached, your OS sends a DNS query to your configured recursive resolver (usually your ISP's DNS or a public resolver like 1.1.1.1).
3. Resolver checks its cache: The recursive resolver also has a cache. If it recently resolved the same domain for another user, it returns the cached answer immediately.
4. Resolver queries a root server: On a cache miss, the resolver asks one of the 13 root server clusters: "Who knows about .com domains?" The root server responds with a referral to the .com TLD nameservers.
5. Resolver queries the TLD server: The resolver asks the .com TLD server: "Who knows about example.com?" The TLD server responds with a referral to example.com's authoritative nameservers.
6. Resolver queries the authoritative nameserver: The resolver asks example.com's nameserver: "What is the IP address of www.example.com?" The authoritative nameserver responds with the A record: 93.184.216.34.
7. Resolver caches and returns the answer: The resolver caches the result according to its TTL and returns the IP address to your device.
8. Browser connects: Your browser uses the IP address to establish a TCP connection to the web server and load the page.

This entire process — steps 1 through 8 — typically takes 20–100ms on the first lookup and is nearly instantaneous on subsequent requests thanks to caching.

DNS Caching and TTL

DNS records include a TTL (Time To Live) value — the number of seconds that resolvers and operating systems should cache the record before querying again. A record with a TTL of 300 will be cached for 5 minutes; one with a TTL of 86400 will be cached for 24 hours.

TTL is a deliberate design choice:

• High TTL (hours/days): Faster resolution for users (cached near them), reduced load on authoritative nameservers. But when you need to change an IP, propagation takes as long as the TTL — potentially 24 hours or more.
• Low TTL (seconds/minutes): Changes propagate quickly (useful during migrations or failovers), but every cache expiry triggers a new lookup chain, adding latency and load.

The common practice is to lower your TTL to 60 seconds before a planned DNS change, make the change, then raise the TTL back to a normal value (300–3600 seconds) once the change is confirmed working.

DNS propagation is the period during which some users see the old record (from their cached version) while others see the new one. It's not a server-by-server rollout — it's simply cache expiry happening at different times across different resolvers globally.

You can look up current DNS records for any domain using the DNS lookup tool.

DNS over HTTPS and DNS over TLS

Traditional DNS queries are sent in plaintext over UDP port 53. This means your ISP, network administrator, and anyone monitoring the network can see every domain you look up — even if the website itself uses HTTPS. This is a significant privacy gap.

DNS over HTTPS (DoH)

DoH encrypts DNS queries inside standard HTTPS traffic (port 443). This makes DNS queries indistinguishable from normal web traffic, preventing ISPs and network observers from reading your DNS lookups. DoH is supported natively in Firefox, Chrome, and Edge, and can be configured to use providers like Cloudflare (1.1.1.1) or Google (8.8.8.8). The trade-off: your DNS queries become visible to the DoH provider rather than your ISP — shifting rather than eliminating the trust requirement.

DNS over TLS (DoT)

DoT encrypts DNS queries inside TLS (the same protocol as HTTPS), using a dedicated port (853). It's more easily distinguished from web traffic and can be filtered by network operators who want to enforce their own DNS policy — making it less useful for bypassing restrictions but simpler to manage in enterprise environments. DoT is widely supported on Android 9+ (Private DNS setting) and in network equipment.

Which Should You Use?

For personal privacy, DoH is more practical — it's harder for ISPs to block and is supported in popular browsers without system-level configuration. For system-wide encrypted DNS on Android, DoT via the Private DNS setting is the easiest option. Both are significantly better than traditional plaintext DNS.

Popular Public DNS Resolvers

Provider	IPv4 Addresses	IPv6 Addresses	Privacy Policy	DoH / DoT
Cloudflare	1.1.1.1 / 1.0.0.1	2606:4700:4700::1111	No query logging (audited)	Yes / Yes
Google	8.8.8.8 / 8.8.4.4	2001:4860:4860::8888	Anonymised after 24–48h	Yes / Yes
Quad9	9.9.9.9 / 149.112.112.112	2620:fe::fe	No PII logging (non-profit)	Yes / Yes
OpenDNS	208.67.222.222 / 208.67.220.220	2620:119:35::35	Logs queries (Cisco)	Yes / No
AdGuard DNS	94.140.14.14 / 94.140.15.15	2a10:50c0::ad1:ff	No logging (ad-blocking)	Yes / Yes

Cloudflare's 1.1.1.1 consistently ranks as the fastest public DNS resolver in global benchmarks. Google's 8.8.8.8 is the most widely known but is run by an advertising company. Quad9 adds a security layer by blocking domains associated with malware and phishing.

Common DNS Issues and How to Diagnose Them

Website Unreachable (DNS Resolution Failure)

If a site is unreachable, test whether the issue is DNS by using nslookup or dig:

# On any OS with nslookup:
nslookup example.com

# On Linux/Mac with dig:
dig example.com A

# Test against a specific resolver:
dig @1.1.1.1 example.com A

If nslookup returns an IP but the site is still unreachable, the issue is connectivity, not DNS. If it returns no result, DNS is failing.

Slow DNS Resolution

Switch to a faster public DNS resolver. Test your current resolver's latency:

# Measure DNS query time (Linux/Mac):
dig example.com | grep "Query time"

Query times above 100ms suggest you should consider a faster resolver.

DNS Cache Poisoning and Stale Cache

If you're seeing an old IP after a DNS change, your OS or router is serving a cached response. Flush the DNS cache:

# Windows:
ipconfig /flushdns

# Mac (macOS Monterey and later):
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd):
sudo systemd-resolve --flush-caches

Split-Horizon DNS Issues

Some networks serve different DNS responses depending on where the query comes from — for example, returning a private IP internally and a public IP externally for the same domain. If a service works on the office network but not from home (or vice versa), split-horizon DNS may be the cause. Test by querying the authoritative nameserver directly to see what it returns, versus what your local resolver returns.

NXDOMAIN vs SERVFAIL

DNS errors come in distinct types. NXDOMAIN means the domain genuinely doesn't exist. SERVFAIL means the resolver couldn't get an answer — often because the authoritative nameserver is unreachable or misconfigured. A SERVFAIL on one resolver but success on another (like 1.1.1.1) points to a problem with your ISP's resolver rather than the domain itself.

Use the DNS lookup tool to inspect any domain's live DNS records and diagnose resolution issues without needing a command line.