DNS
domain name system / nameservers / DNS propagation / TTL
DNS is the system that turns a domain name into the address of the machine that answers for it. Your records live on an authoritative server named in the domain's NS record. Changes are not broadcast; old answers simply sit in caches until the TTL you set expires.
Mozilla describes it as a hierarchical and decentralised naming system for Internet-connected resources, and names the job it is best known for: translating human-friendly domain names into a numeric IP address, a process called a DNS lookup. That is the part everyone knows. The two parts that actually cost people money are where the answers come from and how long they stick around.
The answers come from an authoritative server, which the terminology document defines as a server that knows the content of a DNS zone from local knowledge and can therefore answer queries about it without asking anyone else. That server is named in the domain's NS record. Worth knowing because it is often not the company you bought the domain from, and the person who can change your records is whoever holds that server, not whoever sends the renewal invoice.
How long answers stick around is the TTL, the time to live on each record. The specification quotes the original wording: it specifies the time interval that the record may be cached before the source of the information should again be consulted. That is a number you choose. Set it to five minutes and caches let go in five minutes.
Which brings up the word nobody should be using. Propagation does not appear anywhere in RFC 9499, the IETF's DNS Terminology document. Not once. There is no mechanism by which a change spreads outward across the internet. What exists is caching, bounded by an expiry time you set yourself. When somebody says a change needs to propagate, the answerable question is what the TTL was.
In practice
This is why the answer to how long a change takes is usually wrong. If the TTL on a record is 300 seconds, the old answer is gone from caches in five minutes. If it is 86,400 seconds, it is a day. Since the TTL is read from the record before the change, the moment to lower it is before a migration rather than during one, which is the part that gets skipped.
Not the same as
- Registering the domain
- Renting the name and answering queries for it are separate jobs, often done by different companies.
- Web hosting
- DNS points at a machine. It has no idea whether that machine is working.
Why it matters to you
Almost every launch day disaster and mail outage is a DNS problem, and the window to fix one is set by a decision made before anything broke. Two questions cover most of it: who holds the authoritative server, and what TTL was on the records. If nobody can answer the first, you do not currently control your own domain's behavior, whoever pays the renewal.
What to ask or check
- 01Which server is authoritative for our domain, and who has access to change it?
- 02What is the TTL on the records we are about to change?
- 03If this goes wrong, how quickly can it be put back, and how do we know?
What people get wrong
That a change has to propagate across the internet. The word appears nowhere in the IETF's DNS Terminology document. What happens is caching, bounded by the TTL you chose before the change.
Red flags
- A 24 to 48 hour estimate offered without anyone naming the TTL on the record.
- Nobody able to say which server is authoritative or who can change it.
- A migration date set without lowering TTLs beforehand.
Who owns it
Whoever controls the authoritative server named in the NS records. That is frequently not the registrar, and the difference only becomes visible in an emergency.
Where you will see it
In registrar and hosting control panels, in migration plans, and in every explanation of why a site or mailbox stopped working after a change.