DNS in Computer Networks: How Name Resolution Works

Computers route packets by IP address, but people remember names. DNS is the system that maps one to the other, and it runs every time you open a website, send an email or call an API. In the early ARPANET, every host downloaded one shared file of names and addresses; that stopped scaling, and DNS replaced it in the 1980s with a distributed, hierarchical, cached database (its core specification is RFC 1034 and 1035, from 1987). No single server knows every name, yet any name can be found in a handful of queries.

Why DNS is distributed

DNS does more than turn names into addresses. It also gives one server many names (aliases), tells senders where to deliver a domain's email (MX records), spreads load by returning different addresses to different clients, and holds verification text for services. A single central database would be a single point of failure, a traffic bottleneck and an administrative nightmare. So DNS splits the namespace into zones, each managed by its owner's authoritative name servers, and lets everyone cache answers.

The DNS hierarchy

Names form a tree read from right to left. A fully qualified domain name (FQDN) ends with a dot for the root: www.example.com.

TLDs are generic (gTLDs: .com, .org, .net, and newer ones such as .app) or country-code (ccTLDs: .in, .jp, .uk). Each level delegates the level below it: the root zone lists the name servers for com, the com zone lists the name servers for example.com, and example.com's own servers hold its records. Each root identity is served from many places at once through anycast, where the same IP address is announced from many sites and routing picks the nearest.

Who takes part in a lookup

• Stub resolver: the small DNS client in your operating system. It asks one question and expects a final answer.
• Recursive resolver: the server that does the work, run by your ISP, your company or a public service such as 8.8.8.8 or 1.1.1.1. Its address usually arrives through DHCP.
• Root, TLD and authoritative servers: each answers only for its own part of the tree.

Worked example: resolving www.example.com

Assume every cache is empty and the website's address is 203.0.113.10. The browser checks its own cache, then the operating system its cache and the hosts file; all miss, so the stub resolver asks the recursive resolver. A server that does not hold the answer returns a referral: the NS records of the servers one level down, plus their IP addresses (called glue) so the resolver can reach them.

1. Every cache is empty. Your computer's stub resolver sends one recursive query, recursion desired, to its resolver: give me the A record for www.example.com, the final answer and nothing less.
2. The resolver starts at a root server. The root does not know the answer but returns a referral: the name servers for com, with their addresses (glue).
3. It asks a com TLD server the same question and gets another referral, to the servers for example.com. Each of these queries is iterative: the server answers from what it holds and the resolver does the chasing.
4. The zone's authoritative server, ns1.example.com, answers: www.example.com A 203.0.113.10, TTL 3600.
5. The resolver caches the answer and both referrals, and returns the address to your computer, which caches it too: one question from your computer cost 3 queries upstream.

Many resolvers send each server only the part of the name it needs (QNAME minimisation), so the root sees "com" rather than the full name.

Recursive vs iterative queries

Root and TLD servers never resolve recursively; they would be overwhelmed.

DNS record types

Two rules catch people out. A name with a CNAME may have no other records, so the zone apex (example.com itself, which must have SOA and NS) cannot be a CNAME. And MX and NS records must point to names with address records, not to aliases. Other types you may meet are SRV (the host and port of a service) and CAA (which certificate authorities may issue for the domain).

A small zone file

$TTL 3600
example.com.  IN SOA   ns1.example.com. admin.example.com. (
                       2026100501 ; serial
                       7200       ; refresh
                       900        ; retry
                       1209600    ; expire
                       300 )      ; negative-caching TTL
example.com.  IN NS    ns1.example.com.
example.com.  IN NS    ns2.example.com.
example.com.  IN MX    10 mail.example.com.
www           IN A     203.0.113.10
www           IN AAAA  2001:db8::10
blog          IN CNAME www.example.com.
mail          IN A     203.0.113.25
ns1           IN A     203.0.113.53
ns2           IN A     198.51.100.53

In the SOA, admin.example.com. is the mailbox admin@example.com. Secondary servers copy the zone from the primary and use the serial to tell whether it changed; the refresh, retry and expire timers (in seconds) govern how often they check.

Caching and TTL

Every record carries a TTL in seconds. The recursive resolver, the operating system and the browser may reuse an answer until its TTL runs out, and a cached referral lets the resolver skip the levels above it.

1. At 0 s the cache is empty, so looking up www.example.com takes 3 queries: root, com and example.com. The answer and both referrals are cached, each with its own TTL.
2. At 600 s mail.example.com is new, but the referral to example.com's servers is still cached, so the resolver goes straight there: 1 query instead of three.
3. At 1,800 s www.example.com is asked again. Its A record has 1,800 of its 3,600 seconds left, so the resolver answers from memory without sending a query.
4. At 4,000 s the record expired 400 seconds ago, so the resolver asks example.com's server again, still holding the referral, and the fresh answer starts a new hour.

With TTL 3600, a change to www's address can take up to an hour to reach users whose resolvers cached the old one. What people call "DNS propagation" is just caches expiring. Before moving a site to a new server, administrators lower the TTL (say, to 300 seconds) a day ahead, so the switch takes effect within minutes.

Failures are cached too: a "no such domain" answer (NXDOMAIN) is kept for the negative-caching time in the zone's SOA, so a typo does not hit the authoritative servers on every retry.

DNS over UDP and TCP, port 53

• Queries and answers normally use UDP port 53: one small datagram each way, no handshake. The client retries if no answer arrives.
• Classic DNS limited UDP answers to 512 bytes. A larger answer comes back truncated (the TC flag set) and the client repeats the query over TCP port 53. The EDNS(0) extension lets UDP carry larger answers.
• Zone transfers from a primary to a secondary server (AXFR for the whole zone, IXFR for changes) use TCP port 53.
• Encrypted variants hide queries from on-path observers: DNS over TLS (TCP 853) and DNS over HTTPS (port 443).

nslookup www.example.com      # quick answer from your configured resolver
dig www.example.com A         # full answer with TTL and header flags
dig +trace www.example.com    # follow the referrals from the root yourself
dig -x 203.0.113.10           # reverse lookup (PTR)

Classic DNS answers are not authenticated, which allows cache poisoning: an attacker races the real answer with a forged one so the resolver caches a wrong address. Random query IDs and source ports make guessing hard, and DNSSEC lets resolvers verify records with digital signatures. See network security basics.

Common mistakes

• Saying the root servers know every domain's address: they only refer resolvers to the TLD servers.
• Mixing up who sends which query: the stub's query is recursive, the resolver's queries are iterative.
• Saying DNS uses only UDP: TCP is used for zone transfers and truncated answers.
• Putting a CNAME at the zone apex or pointing an MX record at a CNAME.
• Thinking a DNS change "propagates" by being pushed: old answers simply live in caches until their TTL expires.
• Reading MX preference backwards: the lowest number is tried first.

Interview questions

Walk me through what happens when a domain name is resolved. The browser and OS caches are checked first. On a miss, the stub resolver asks the recursive resolver, which asks a root server (referral to the TLD servers), a TLD server (referral to the domain's authoritative servers) and finally an authoritative server, which returns the record. Every party caches the answer for its TTL.

What is the difference between an authoritative server and a recursive resolver? An authoritative server holds the original records for a zone and answers only for that zone. A recursive resolver holds no zones of its own; it finds answers on behalf of clients by following referrals, and caches what it learns.

Why can a DNS change take hours to show up? Resolvers and clients keep cached copies of the old record until its TTL expires. If the TTL was a day, some users keep seeing the old address for up to a day. Lowering the TTL before a planned change shortens that window.

What is an MX record, and what does its preference number do? An MX record names the mail server that accepts email for a domain. A domain can list several; senders try the one with the lowest preference number first and fall back to higher numbers if it is unreachable.

When does DNS use TCP instead of UDP? For zone transfers between primary and secondary servers, and when an answer is too large for a UDP response: the server sets the truncation flag and the client repeats the query over TCP. DNS over TLS also runs on TCP.

What is a reverse DNS lookup, and where is it used? It maps an IP address back to a name through a PTR record under in-addr.arpa (ip6.arpa for IPv6). Mail servers check that a sending server's address has a sensible reverse name, and logging and diagnostic tools show names instead of numbers.

What is DNS cache poisoning, and how is it prevented? It is tricking a resolver into caching a forged record, so its users are sent to an attacker's address. Defences include randomised query IDs and source ports, which make forged replies hard to match, and DNSSEC, which signs records so resolvers can verify them.

Next, read HTTP and HTTPS, and test yourself with the Computer Networks (Basic) skill test.