DNS (Domain Name System)

By Sitraka Forler · Lecturer, Durham Business SchoolUpdated 3 October 2026 About this site

The internet's address book: it translates domain names into IP addresses.

DNS stores records for each domain: A and AAAA give its IPv4 and IPv6 addresses (Internet Protocol versions 4 and 6), CNAME (canonical name) points one name at another, and MX (mail exchange) names its mail servers. DNS servers cache each answer for the record's TTL (time to live), so after a change some users may get the old address until it expires, which is why a moved site can work for you but not a colleague.

The intuition

Networks move packets between numeric addresses such as 203.0.113.10, while people, browsers and configuration files use names such as reports.example.com. DNS is the lookup that joins the two, and its central trick is that no single server knows every name. The namespace is a tree read from right to left. At the top sits the root, written as the usually invisible trailing dot in reports.example.com., below it top-level domains such as com, lu and uk, below those domains such as example.com, and below those any names their owners create. Each level delegates the level beneath to whoever runs it: the root knows who answers for com but nothing below that, the com servers know who answers for example.com, and example.com's own servers hold the actual records. Picture a chain of reception desks, each unable to answer your question but always able to tell you which desk to try next.

Four roles share the work. The stub resolver inside your operating system sends its question, flagged recursion desired, meaning please do the whole job, and waits. The recursive resolver, run by your internet provider, your employer or a public service, does the legwork: it asks a root server, follows the referral to the servers for com, then follows the next referral to the authoritative servers for example.com, and only they answer with the flag that marks a reply as authoritative. The answer is a set of typed records. A holds an IPv4 address, AAAA an IPv6 address, CNAME declares the name an alias of another name, MX lists the mail servers with a preference number, lowest tried first, and TXT carries free text, used for mail authentication such as SPF and for proving to a service that you control the domain. Every record carries a TTL in seconds, and the resolver caches each one, referrals included, for up to that long.

Caching is what makes DNS fast and cheap, and it is also why the operations saying "it is always DNS" keeps coming true. Almost every connection starts with a lookup, so a DNS fault takes down services that have nothing to do with names, and it rarely looks like DNS: it shows up as a timeout, a certificate error or an application that works for one colleague and fails for the next, because each sits behind a different cache holding a different answer for a different length of time. Mistakes also outlive their fixes. A bad record, or a cached "no such name", stays in resolvers until its TTL runs out, and nothing pushes the correction. Practitioners work with that clock rather than against it: they lower a TTL at least one old TTL before a planned change, ask the authoritative server directly with dig to see what is really published, run at least two authoritative servers on separate networks, and review DNS edits like any other production change.

Example

# its IPv4 address(es)
dig example.com A +short
# its IPv6 address(es)
dig example.com AAAA +short
# full answer: the 2nd column is the seconds left in the cache (at most the TTL)
dig example.com A +noall +answer
# the same lookup, also built into Windows
nslookup example.com

Resolving reports.example.com from a cold cache, then watching the TTLs run down

Set the scene. Your laptop's stub resolver is configured to use the recursive resolver at 192.0.2.53 (on many Linux systems, the line nameserver 192.0.2.53 in /etc/resolv.conf), and that resolver has just started. A real resolver starts from a root hints file it ships with and confirms the current list of root servers with one priming query; that step is done, and otherwise its cache is empty. Every address in this example comes from the documentation ranges, 192.0.2.0/24, 198.51.100.0/24 and 203.0.113.0/24 for IPv4 and 2001:db8::/32 for IPv6, so none of them will answer if you try.
The stub asks and waits. The browser needs reports.example.com, the operating system finds nothing in its hosts file or its own cache, and sends a query, name reports.example.com, type A, with the recursion desired (rd) flag set, over UDP to port 53 on 192.0.2.53. It sends a matching AAAA query too, because the browser will use IPv6 if it can. From here the stub only waits: it never talks to the root itself.
Hop 1, the root. The resolver sends the question to a root server, here 198.51.100.1. The root holds no records for example.com, so it replies with a referral: an empty answer section, the delegation com. 172800 IN NS a.gtld-servers.net. in the authority section, and that server's address, here 198.51.100.30, in the additional section. 172800 seconds is 172800 / 3600 = 48 hours, so while that referral stays cached the resolver skips the root for every .com name. (A resolver using QNAME minimisation asks the root only about com, which reveals less of your lookup; the referral it gets back is the same.)
Hop 2, the com servers. The resolver asks 198.51.100.30 and gets a second referral: example.com. 172800 IN NS ns1.example.com. and example.com. 172800 IN NS ns2.example.com. in the authority section, plus the glue records ns1.example.com. 172800 IN A 203.0.113.53 and ns2.example.com. 172800 IN A 198.51.100.53 in the additional section. The glue is essential here: both name servers sit inside the zone they serve, so without their addresses the resolver would need example.com to find example.com.
Hop 3, the authoritative server. The resolver asks ns1.example.com at 203.0.113.53, which replies with the authoritative answer (aa) flag set and two records: reports.example.com. 3600 IN CNAME web.example.com. and web.example.com. 300 IN A 203.0.113.10. The name was an alias, and because its target lives in the same zone, the server includes the target's address in the same reply. The AAAA query ends the same way, with web.example.com. 300 IN AAAA 2001:db8::10.
Count the cost and read the cache. From that cold start, the A lookup took 3 upstream queries by the resolver (root, com, example.com) plus 1 exchange with your stub, 3 + 1 = 4 exchanges in all. The reply to your stub carries the recursion available (ra) flag and no aa flag, because the resolver is passing on records that someone else publishes. It now holds four record sets that matter here, each on its own clock: the com delegation for up to 172800 s (48 hours), the example.com delegation for up to 172800 s (48 hours), the CNAME for up to 3600 s (1 hour) and the A record for up to 300 s (5 minutes). "Up to" because resolver software may cap cache lifetimes: Unbound, for example, keeps nothing longer than 86400 s (24 hours) by default.
Ask again 120 seconds later, from a colleague's laptop behind the same resolver: dig reports.example.com A +noall +answer prints reports.example.com. 3480 IN CNAME web.example.com. and web.example.com. 180 IN A 203.0.113.10. Those are 3600 - 120 = 3480 and 300 - 120 = 180 seconds left, and the resolver sent 0 upstream queries. When the A record expires 180 seconds later, the next lookup costs 1 upstream query, to one of the example.com name servers only, because the CNAME still has 3480 - 180 = 3300 seconds to run and both delegations far longer.
Now move the service. At 10:00:00 you change web.example.com to 203.0.113.20, and both authoritative servers start serving the new record at once. A resolver that cached the old record at 09:58:00 keeps answering 203.0.113.10 until 09:58:00 + 300 s = 10:03:00, and one that cached it at 09:59:59 keeps it until 09:59:59 + 300 s = 10:04:59, so the old address can survive for up to the full 300 seconds after the edit. Had the TTL been 86400, that window would be 86400 / 3600 = 24 hours, which is why teams lower the TTL to 300 at least 24 hours before a planned move and raise it again once the move has settled.

A cold lookup walks the root, the TLD and the authoritative server once, and from then on each cached record's TTL decides when each resolver sees a change, however quickly you publish it.

Common pitfalls

Lowering the TTL at the moment of the change. A resolver keeps the TTL it was handed when it fetched the record, so dropping 86400 to 300 in the same edit as the move still leaves some users on the old address for up to 24 hours. Lower it at least one old TTL ahead of the change, and keep the old server running until that window has closed.
Putting a CNAME beside other records. A CNAME must be the only record at its name, and the zone apex, example.com itself, must hold SOA and NS records, so the apex cannot be a CNAME, and neither can any name that also needs MX or TXT. Publish A and AAAA records there, or use the ALIAS or flattening feature many DNS providers offer, which resolves the target on their side and serves plain address records.
Dropping the trailing dot in a zone file. In zone file syntax a name without a final dot is relative to the zone, so writing web.example.com as a CNAME target inside the example.com zone publishes web.example.com.example.com, which does not exist. Write fully qualified names with the dot, as in web.example.com., and check what was actually published with dig rather than rereading the file.
Testing a change through a cache. Your browser, your operating system and your resolver may each hold an old answer, so one lookup that returns the new address proves little, and one that returns the old address does not mean the edit failed. Ask the authoritative server directly, for example dig @ns1.example.com web.example.com A +norecurse, to see what is published, then query one or two other resolvers to see what everyone else may still be served.
Looking a name up before it exists. A resolver that receives NXDOMAIN, meaning no such name, caches that negative answer as well, for up to the lesser of the SOA record's own TTL and the SOA minimum field, so creating the record a minute later does not help anyone behind that resolver until the negative entry expires. Create records before you test, announce or link to them.

Frequently asked questions

What is DNS in simple terms?

DNS, the Domain Name System, is the internet's lookup service for names: you give it a name such as www.example.com and it returns the records stored for that name, most often the IP address a computer needs in order to connect. It is distributed, so each organisation runs the part of the namespace it owns, and no single server holds the whole list. Almost every connection your computer makes starts with a DNS lookup.

How does DNS work step by step?

Your operating system's stub resolver sends the question to a recursive resolver. If that resolver has nothing cached, it asks a root server, which refers it to the servers for the top-level domain such as com; those refer it to the domain's authoritative name servers, which return the record. The resolver passes the answer back and caches every piece of it for up to its TTL, so the next lookup for a name in the same domain usually skips the root and the TLD servers entirely.

What is the difference between a recursive resolver and an authoritative name server?

An authoritative name server publishes the records for the zones its owner manages and answers only for those, with a flag marking the reply as authoritative. A recursive resolver publishes nothing of its own: it chases referrals from the root down to the right authoritative server on behalf of its clients, then caches what it learns. Your laptop talks to a recursive resolver, and the recursive resolver talks to authoritative servers.

What are A, AAAA, CNAME, MX and TXT records?

A and AAAA records map a name to an IPv4 or an IPv6 address. A CNAME says the name is an alias of another name, so the lookup continues at that target; it must be the only record at its name, which is why the bare domain, example.com itself, cannot be a CNAME: it must also hold SOA and NS records. MX names the servers that accept mail for the domain, each with a preference number, lowest tried first, and TXT holds free text used for mail authentication such as SPF and DKIM and for proving domain ownership to a service.

What is TTL in DNS, and why do DNS changes take time to propagate?

TTL, time to live, is the number of seconds a resolver may keep a record in its cache before it must ask again. Nothing pushes a change out across the internet: each resolver keeps serving its cached copy until that copy's TTL runs out, so a record with a TTL of 3600 can stay stale for up to an hour after you edit it. To make a planned change land quickly, lower the TTL at least one old TTL beforehand, then raise it again once the change has settled.

Why is it always DNS when something breaks?

The saying sticks because nearly every service depends on DNS and its failures rarely announce themselves. A broken record, an expired domain, an unreachable resolver or a cached negative answer surfaces as a timeout, a certificate warning or an application error, and caching makes the fault hit some users and not others, then linger after the fix. Checking resolution early, with dig or nslookup against both your usual resolver and the authoritative server, can save hours of searching in the wrong place.

Test yourself

Practise DNS (Domain Name System) hands-on - free, in your browser

The OSI Model & TCP vs UDPIT Essentials · 14 min · no signup neededStart