DNS explained: how a domain name becomes a website
You type a name, a website appears. In between, four separate servers get consulted in under 50 milliseconds. Here is the journey, and why changing a record takes longer than making it.
Type example.com and press enter. Before your browser can send a single byte of an HTTP request, it has to find out where example.com is — and that lookup involves consulting up to four different servers, usually completes in well under 50 milliseconds, and happens invisibly on every first visit to every domain.
Let us follow one.
The journey of a single lookup
Your browser and OS check their own caches
Both keep recent answers. If either has one that has not expired, the lookup ends here in microseconds. Most lookups on a busy machine never leave it.
The recursive resolver is asked
Usually run by your ISP, or a public one like 1.1.1.1 or 8.8.8.8. It is the component that does the actual hunting, and it caches heavily on behalf of everyone using it.
The resolver asks a root server
There are 13 root server addresses, served by hundreds of anycast instances worldwide. The root does not know where example.com is. It knows who is responsible for .com, and says so.
Then the TLD server
The .com nameservers do not know the address either. They know which nameservers are authoritative for example.com — the ones your registrar points at — and return those.
Then the authoritative nameserver
This one holds the actual records, and finally answers: example.com is at this address, and here is how long you may remember that.
Everyone caches the answer
The resolver stores it, your OS stores it, your browser stores it. The next lookup for the same name skips most of the journey entirely.
That chain looks slow written out, and it would be if it happened every time. It does not. Root and TLD answers are cached for hours or days by every resolver on earth, so in practice a resolver almost always starts partway down the chain, and a repeat visitor's browser often skips it altogether.
The records worth knowing
| Record | What it does | Typical use |
|---|---|---|
| A | Maps a name to an IPv4 address | Pointing a domain at a server |
| AAAA | Maps a name to an IPv6 address | The same, for IPv6 |
| CNAME | Maps a name to another name | Pointing www at a CDN hostname |
| MX | Says where email for the domain goes | Mail hosting |
| TXT | Holds arbitrary text | SPF, DKIM, domain verification |
| NS | Names the authoritative servers | Delegating a domain or subdomain |
| CAA | Says which authorities may issue certificates | Preventing unauthorised certificates |
Pointing a domain at a CDN normally means changing an A record or a CNAME so the name resolves to the edge network rather than to your origin. That single record change is what puts the CDN in front of your site.
The apex record problem
One wrinkle that catches nearly everyone. The DNS specification does not allow a CNAME at the apex of a domain — example.com itself, as opposed to www.example.com — because a CNAME cannot coexist with the other records the apex must carry, such as MX and NS. Point your apex at a CNAME and your email may stop working.
Providers work around this with features variously called CNAME flattening, ALIAS or ANAME records, which resolve the target behind the scenes and return an A record. If you need your bare domain on a CDN, either use a provider offering that or use a plain A record and accept that you will have to update it manually if the address changes.
TTL, and why changes take time
Every DNS record carries a time to live: how many seconds a resolver may cache the answer before asking again. It is the reason DNS scales — without caching, root and TLD servers would field every lookup on the internet — and it is also the reason changes are not instant.
When you change a record, the new value is served immediately by your authoritative nameservers. But every resolver that already has the old answer keeps serving it until its copy expires. With a 24-hour TTL, some visitors will be reaching the old address a full day after you made the change.
Lower the TTL before a planned change, not during it. Drop it to 300 seconds a day or two ahead, wait for the old long TTL to expire everywhere, then make the change — it now propagates in minutes. Raise it again afterwards. Lowering the TTL at the same moment you change the record achieves nothing, because resolvers are still holding the old record with its old TTL.
Two further realities worth knowing. Some resolvers ignore short TTLs and impose their own minimum, so "propagation" is never perfectly predictable. And browsers maintain their own DNS caches that outlive the OS cache, which is why a change can appear to have worked everywhere except on the machine of the person who made it.
When it breaks, check in this order
- Query your authoritative servers directly.
dig @ns1.yourprovider.com example.comshows what is actually published, bypassing every cache in between. If this is wrong, nothing downstream matters. - Then query a public resolver.
dig @1.1.1.1 example.comtells you what the wider internet currently sees, which may still be the old value. - Check the TTL in the answer. It counts down as the cached copy ages, so it tells you how much longer the stale answer will live.
- Confirm the nameservers at the registrar. If the NS records at your registrar point somewhere you are not editing, you have been changing records nobody is asked about.
Frequently asked questions
What is DNS?
DNS, the Domain Name System, translates human-readable domain names such as example.com into the numeric IP addresses computers use to reach each other. Every connection to a website begins with a DNS lookup, which is answered either from a cache or by consulting root, top-level domain and authoritative nameservers in turn.
How long does DNS propagation take?
It depends on the TTL that was set on the record before you changed it, not on the new value. Resolvers holding the old answer keep serving it until their copy expires, so a record with a 24-hour TTL can take a full day to update everywhere. Lowering the TTL a day or two before a planned change reduces this to minutes.
What is the difference between an A record and a CNAME?
An A record maps a name directly to an IPv4 address. A CNAME maps a name to another name, which must then be resolved in turn. CNAMEs are useful for pointing a subdomain at a provider's hostname, since the provider can change the underlying address without you editing anything. A CNAME cannot be used at the apex of a domain.
Why can I not use a CNAME on my root domain?
Because the DNS specification does not permit a CNAME to coexist with other records at the same name, and the apex of a domain must carry NS and usually MX records. Using a CNAME there can break email delivery. Providers offer CNAME flattening, ALIAS or ANAME records to work around this by resolving the target and returning an A record instead.
What is a TTL in DNS?
The time to live is the number of seconds a resolver may cache a record before it must ask again. Longer TTLs reduce lookup traffic and improve performance; shorter ones make changes propagate faster. Common values range from 300 seconds for records you expect to change to 86,400 seconds for stable ones.
How do I point my domain at a CDN?
Usually by changing a CNAME record so that your hostname, such as www.example.com, resolves to the hostname the CDN provides, rather than to your origin server's address. For a bare apex domain you will need an A record or your provider's CNAME flattening equivalent. Lower the TTL beforehand so the change takes effect quickly, and test on the CDN's temporary hostname before switching.
DNS is a distributed lookup that turns names into addresses, answered by a chain of root, TLD and authoritative servers and cached aggressively at every step. Learn the handful of record types that matter, remember that the apex cannot take a CNAME, and lower your TTL before you change anything. Most DNS pain is caching working exactly as designed.
See how NordicCDN does this for your site:
Mads has worked in IT — mostly hosting — since he was 16. He took an early stake in a SaaS company and helped grow it through to its acquisition by Visma, has built and run data-center networks, and served as CTO of a Danish data center. He started NordicCDN to make fast, secure infrastructure simple to use.
