DNS explained for server owners: records, TTLs and propagation

You move a website to a new server, change its A record, and reload. Your phone shows the new site. A colleague on another network still gets the old one, and the advice you find online says DNS "propagation" can take up to 48 hours. So you wait and refresh, with no way to tell whether the hours are nearly over or have barely started.

Nothing is propagating. No server pushes your change outward. What exists instead is a large number of caches, each holding a copy of your old record with an expiry time that you, or whoever set up the domain, chose. Once you know where the copies sit and how their clocks run, you can work out when the last one will be thrown away, and plan a change so the wait is five minutes rather than a day.

Your laptop, and four kinds of server behind it

When a program on your laptop needs the address of www.example.com, it does not work the answer out itself. It hands the question to a small part of the operating system called a stub resolver, which the DNS terminology RFC describes as a resolver that leaves the real work to a recursive one.¹

That recursive resolver is usually run by your internet provider, your company, or a public service you chose, such as 1.1.1.1 or 8.8.8.8. It does the legwork: it asks other servers, follows their directions and, as RFC 9499 notes, normally keeps what it learns in a cache.¹ The servers it asks come in three layers, and each one knows only its own part of the tree.

Only the last server in that chain holds the answer. In RFC 9499's terms, an authoritative server answers for a zone from data it holds itself, with no need to ask another server.¹ Everything above it deals in referrals: pointers to the servers one level further down.

The root: 13 names, about 2,000 instances

A lookup that finds nothing useful in the cache starts at the root. A resolver is configured with a root hints file holding the names and addresses of the root servers, which is how it knows where to begin.³

You will often read that there are 13 root servers. There are 13 root server names, a.root-servers.net to m.root-servers.net, and it is those 13 names that the root zone lists.⁴ Behind them are 12 independent operators and more than 2,000 operational instances (root-servers.org, September 2026).⁵

Root server names, from A to M

13

Independent organisations that operate them

12

Operational root server instances, September 2026

2,000+

One lookup, from a cold cache

Here is the walk for a resolver with an empty cache, numbered as in the drawing at the top of the page.

1. 1

   Your laptop asks the resolver

   The stub resolver asks for the A record for www.example.com with the recursion desired flag set, which means "find the whole answer for me".

2. 2

   The resolver asks a root server

   It sends the same question to one of the root servers from its hints file.

3. 3

   The root refers it to .com

   The root does not hold example.com. It replies with a referral: the NS records naming the .com servers, with their addresses.

4. 4

   The resolver asks a .com server

   The same question again, one level down.

5. 5

   The .com server refers it to example.com's servers

   Another referral, to ns1.example.com and ns2.example.com. Those names sit inside the zone they serve, so the referral carries their addresses too.

6. 6

   The resolver asks ns1.example.com

   Now it is talking to a server that holds the zone itself.

7. 7

   The authoritative server answers

   It returns the record, 192.0.2.10, with a TTL of 3600 seconds and the authoritative answer flag set.

8. 8

   The resolver caches everything and replies

   It stores the answer and both referrals, then passes the answer back to your laptop.

That is RFC 1034's resolver algorithm with the details filled in: check the cache, pick the closest servers it knows of, ask them, and when a reply points somewhere closer, cache the pointer and repeat.²The addresses that ride along with the referral in step 5 are what the same RFC calls "glue".²

Your laptop asked recursively, handing the whole job over. The resolver asked each server iteratively: each one answered from what it held or pointed further down, and none chased the answer on the resolver's behalf. RFC 1034 defines both modes, and requires every name server to support the non-recursive one.²

The cache is what keeps this cheap. The next client to ask for www.example.com within the hour gets step 8 straight away, and a client asking for mail.example.com skips steps 2 to 5, because the resolver already knows where example.com's servers are. When the full walk has to happen again is decided by one number on the record: its TTL.

All of these questions and answers normally travel as UDP datagrams to port 53, with TCP on the same port for replies too long for a datagram.⁶ A short UDP question that draws a much longer reply is also what attackers abuse to multiply their traffic; amplification attacks explains how.

Resolving the name is only the first step of loading a page. The connection, encryption and request that follow are in what happens when you open a website.

Records: what a zone actually holds

A zone is a list of resource records. Whether you meet one in a DNS provider's dashboard, a zone file or the output of dig, every record has the same five parts.

Records that share a name, class and type form an RRset. A query returns the whole set, and every record in it must carry the same TTL,⁷ so two A records for example.com are cached together and expire together.

These are the types you will actually edit, with their codes from IANA's registry.⁸The examples use names and addresses reserved for documentation: example.com,⁹ 192.0.2.0/24 and 203.0.113.0/24,¹⁰ and 2001:db8::/32.¹¹

A and AAAA: where the name lives

An A record holds a 32-bit IPv4 address.⁶ An AAAA record holds a single 128-bit IPv6 address.¹² A name can have both, and a client with IPv6 connectivity may use either. That makes AAAA the classic thing to forget in a move: you update the A record, the old AAAA still points at the old server, and some of your visitors keep reaching it.

CNAME: an alias, and nothing else

A CNAME makes a name an alias for another, its canonical name. A resolver that meets one restarts its lookup at the canonical name.² The rule that catches people out is that a CNAME must be alone. RFC 1034 says a name that holds a CNAME should hold nothing else,² and RFC 2181 makes that firm, allowing only DNSSEC's own records beside it.⁷

Two consequences follow, plus a separate rule, and the drawing shows all three. First, no CNAME at the zone apex, the name that owns the zone's SOA and NS records,¹ because those records have to live there. RFC 1912 describes what happens when someone tries: the server sees the CNAME, ignores the NS records, and every host in the domain goes with them.¹³ Second, no CNAME on a name that also needs MX or TXT records. Separately, RFC 2181 says the name an MX or NS record points to must not itself be an alias.⁷

So at the apex, use A and AAAA records, and put the CNAME on www or another name below it. Some DNS providers offer a non-standard "alias" or "flattening" option for the apex, which looks up the target itself and answers with plain A and AAAA records. It is a provider feature, not a record type the standards define.

MX, TXT and CAA: mail, proofs and certificates

An MX record names a mail server for the domain with a 16-bit preference, lowest first:⁶ with MX 10 mail1 and MX 20 mail2, senders try mail1 first. A TXT record holds text whose meaning depends on where it sits,⁶ which in practice means conventions: an SPF policy, listing the servers allowed to send your domain's mail, must be published as TXT,¹⁴ and services that want proof you own a domain usually ask for a token in one.

A CAA record names the certificate authorities allowed to issue certificates for a domain, and a compliant authority must check for one and refuse a request that does not match it.¹⁵ It checks the requested name, then each parent in turn, so a CAA record on example.com also covers www.example.com unless www has its own.¹⁵ Name one authority, forget that your certificates come from another, and the next renewal fails.

NS, SOA and PTR: the plumbing

NS records name a zone's authoritative servers, and appear twice: in the zone itself, and in the parent zone, which hands them out as the referral in step 5. The SOA record, one per zone, carries the zone's serial number and its timers.⁶ The last of them, MINIMUM, is the field RFC 2308 later redefined as the TTL for negative answers.¹⁷

PTR records run the other way, from an address to a name, in a tree of their own with the address written backwards: the PTR for 192.0.2.10 sits at 10.2.0.192.in-addr.arpa, so that each network's block of addresses can be delegated as a zone of its own.⁶ A server's PTR record is therefore not in your domain's zone at all. It belongs to whoever holds the address block, which for a rented server means the provider.

TTL: how long a copy may live

A record's TTL is a number of seconds, set by whoever runs the zone, that limits how long a cache may keep a copy before discarding it.² RFC 2181 settled its range at 0 to 2,147,483,647 seconds,⁷ about 68 years at 31,536,000 seconds a year. Three details decide how the number you choose behaves.

• The clock starts when a resolver fetches the record, not when you edit it. RFC 1034 observes that caches typically turn the TTL into an absolute expiry time when they store a record.²A resolver that fetched your record at 09:59 with a TTL of 3600 keeps it until 10:59, whatever you do at 10:00.
• The TTL is a maximum, not a promise. A cache may put its own upper bound on TTLs and drop a copy early; RFC 2181 calls the TTL "a maximum time to live, not a mandatory time to live".⁷Keeping a copy longer is another matter. The one exception is for outages: when a resolver cannot reach any of a zone's servers, RFC 8767 lets it answer from expired data, with a TTL of 30 seconds recommended, rather than fail.¹⁹ It never delays a normal change.
• Zero means do not cache. A record with a TTL of 0 may answer the query at hand and should not be kept.⁶ It is legal, but every lookup then travels all the way to your authoritative servers.

RFC 1034 suggested TTLs measured in days for an ordinary host, and in the same paragraph described the technique this guide is built around: lower the TTL before a change you can foresee, then raise it back afterwards.² Today, an hour or more suits records that rarely change, and a few minutes only a planned move: a short TTL shrinks the window after a change but multiplies how often every resolver comes back to ask.

Why a change seems to take hours

RFC 1034 put access to information ahead of instant consistency: changes "percolate out" as caches refresh, with no promise that every copy changes at once.²

When you save a changed record, your authoritative servers start handing out the new version. (Secondary servers check for a new copy when the SOA's refresh timer comes round,⁶ or sooner if the primary sends a NOTIFY.¹⁶) Every resolver that already holds a copy carries on serving it until the copy expires, and fetches the new one the next time a client asks after that. Nothing tells the resolvers that anything changed.

The latest a resolver can have fetched the old record is a moment before your change, so the last old copy expires one full TTL later: an hour at 3,600 seconds, a day at 86,400. Two people see different things at the same moment because their resolvers fetched at different times. The "48 hours" of folklore is not a property of the internet. It is somebody's TTL.

Your own machine can hold a copy too: operating systems and browsers may cache answers in front of the resolver. Flushing them fixes what your machine shows and nothing else; every resolver keeps its copy for the rest of the TTL.

"Does not exist" is cached too

Resolvers also remember that something is missing. A name that does not exist gets an NXDOMAIN answer; a name that exists but has no record of the type asked for gets what RFC 2308 calls NODATA.¹⁷ Both arrive with the zone's SOA record, and a resolver may cache the negative answer for the smaller of the SOA's MINIMUM field and the SOA record's own TTL.¹⁷

Take a zone whose SOA has a TTL of 3,600 and a MINIMUM of 1,800. You open new.example.com to see whether it works, before creating the record. Your resolver gets NXDOMAIN and keeps it for the smaller figure, 1,800 seconds. You create the record a minute later, and your resolver goes on saying it does not exist for up to 29 more minutes, while everyone who had not asked sees it at once. Create records first, then test them.

Changing name servers is slower still

Moving a domain to a different DNS provider changes its NS records in both places they live: your zone, and the parent zone that hands out the referral. The copy in the parent carries a TTL set by the registry, not by you, and it can be long: the root zone, for instance, hands out the .com delegation with a TTL of 172,800 seconds,¹⁸ which is 48 hours (172,800 ÷ 3,600), the very figure the propagation folklore quotes.

Resolvers that have already asked the old servers also hold the old zone's own NS records. Those came in an authoritative reply, which RFC 2181 ranks above the parent's referral,⁷ so such a resolver can keep asking the old servers until that NS TTL runs out. Lower it at the old provider at least one old TTL ahead, then wait out whichever is longer: the parent's delegation TTL (dig shows it, below) or the old zone's NS TTL. Keep the old provider serving identical records until then.

Changing a record without a gap

The zone has www.example.com. 3600 IN A 192.0.2.10, and the site is moving to a new server at 203.0.113.20. The goal: every visitor on the new server within minutes of a moment you choose, with the old server still answering anyone who arrives late.

1. 1

   75 minutes before: lower the TTL and change nothing else

   Edit the record so its TTL reads 300 instead of 3600, with the same address. A resolver that fetched it a second earlier still holds a copy with 3,600 seconds on it, so the new TTL only governs every cache after one full old TTL: 60 minutes. Add a margin and wait 75.

2. 2

   The moment: change the address

   Set the A record to 203.0.113.20, and the AAAA record too if the name has one. Every copy still in circulation now has at most 300 seconds left.

3. 3

   5 minutes later: every old copy has expired

   In the worst case, a resolver fetched the old address a second before the change and serves it for 299 more seconds. Then every resolver that honours TTLs is on the new server.

4. 4

   Keep the old server running

   Leave it serving the site, or passing requests to the new one, for a day or so, for anything that does not follow the standards. Check the new address from outside with dig.

5. 5

   Raise the TTL again

   Once you are satisfied, set the TTL back to 3600, so resolvers stop asking every five minutes.

From the first edit to the last cache on the new address took 80 minutes, and only the last 5 were a window in which different visitors could reach different servers. Change the address directly with the TTL at 3,600 and that window is up to an hour; at 86,400 it is up to a day.

The same plan works for an MX record: lower its TTL first, and keep the old mail server accepting messages until the last cached copy of the old MX has expired.

Reading dig output

dig, from the BIND project, asks one DNS question and prints the whole reply. Two queries tell you most of what you need after a change: what a resolver has cached, and what the authoritative server holds. Swap in your own domain and the name servers dig reports for it.

$ dig @1.1.1.1 www.example.com A;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38404;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;; QUESTION SECTION:;www.example.com.            IN      A;; ANSWER SECTION:www.example.com.     2917    IN      A       192.0.2.10;; Query time: 12 msec;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)

• status is NOERROR when the name exists. NXDOMAIN, response code 3, means the name does not exist; RFC 1035 gives it meaning only when it comes from a server authoritative for the zone.⁶A resolver passes it on and caches it like any other answer.¹⁷
• flags: qr marks a response. dig set rd, recursion desired, because it sends recursive queries by default.²⁰ ra says the server offers recursion. The flag that is missing is aa: the answer came from a resolver, not from a server authoritative for the name.⁶ The TTL shows it was sitting in that resolver's cache.
• 2917 is the TTL. In a cache, TTLs count down while the zone's own copy keeps its configured value,⁶ so from a resolver this is roughly the time its copy has left, not the value you set. Run the same query a few seconds later and you will usually see it lower.

$ dig @ns1.example.com www.example.com A +norecurse;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5120;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;; ANSWER SECTION:www.example.com.     3600    IN      A       192.0.2.10

Here aa is set and the TTL is the full 3,600 you configured. +norecurse clears the rd bit: you want the source's own answer, not a lookup elsewhere.²⁰ Because both queries name their server with @, they go straight to it, and no cache on your own machine is involved.

Put the two side by side after a change and you can predict the moment. If the authoritative server already answers 203.0.113.20 and the resolver still answers 192.0.2.10 with 2,917 seconds left, that resolver switches within 48 minutes and 37 seconds at the latest (2,917 s = 48 × 60 + 37).

$ dig example.com NS +shortns1.example.com.ns2.example.com.$ dig @ns1.example.com example.com SOA +norecurse +noall +answerexample.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. 2026092801 7200 3600 1209600 1800

+short trims the output to the bare answers.²⁰ The SOA record lists the primary server, the mailbox of whoever is responsible for the zone, the serial number, then the refresh, retry and expire timers and, last, MINIMUM.⁶ With 3,600 on the SOA and 1,800 in MINIMUM, a "does not exist" answer from this zone can be cached for 1,800 seconds, the smaller of the two.

dig +trace www.example.com does the resolver's walk itself: it starts at the root servers, follows each referral with iterative queries and prints every step.²⁰ It is the quickest way to see the delegation the .com servers hand out for your domain, TTL included, and to catch a registrar still pointing at your old DNS provider.

Mistakes that turn a five-minute change into a lost day

• Moving the A record and forgetting the AAAA. Visitors with IPv6 keep reaching the old server.
• Switching off the old server as soon as the record is saved. Every cache still holding the old address sends visitors to a dead machine until it expires.
• Deleting the zone at the old DNS provider the day you change name servers. Resolvers keep asking the old servers until the longer of the parent's delegation TTL and the old zone's own NS TTL runs out.
• A CAA record that leaves out your certificate authority. The next issue or renewal is refused.