By Rohit V.7 min readArticle
How DNS Works, Explained for Developers (2026)
TF
ToolsFuel Team
Web development tools & tips
Photo by Unsplash on Unsplash
Table of Contents
The Short Version
> Quick answer: DNS turns a domain name into an IP address through a chain of lookups — root servers, then the top-level domain servers, then the domain's authoritative nameservers — with aggressive caching at every step. That caching is why a record change takes hours to be visible everywhere, and why the TTL you set matters more than the change itself.
Most developers learn DNS reactively, at 2am, when something isn't resolving. That's a bad time to learn it.
The model is simpler than the folklore suggests. There's no mysterious global propagation process — there's a hierarchy of servers and a lot of caches with expiry timers, and "propagation" is just those timers running out.
Once that clicks, most DNS problems become diagnosable in about two minutes with one command.
Most developers learn DNS reactively, at 2am, when something isn't resolving. That's a bad time to learn it.
The model is simpler than the folklore suggests. There's no mysterious global propagation process — there's a hierarchy of servers and a lot of caches with expiry timers, and "propagation" is just those timers running out.
Once that clicks, most DNS problems become diagnosable in about two minutes with one command.
What Happens Before Your Request
Type a domain and your machine checks caches first — the browser's own cache, then the OS resolver cache, then the hosts file. Any hit ends the process immediately, which is why your changes work for a colleague and not for you.
Miss all of those and the query goes to a recursive resolver, usually your ISP's or something like a public resolver. The recursive resolver does the actual work on your behalf.
It asks a root server, which doesn't know your domain but knows who handles `.com`. It asks the `.com` servers, which don't know your IP but know your domain's authoritative nameservers. It asks those, and gets the answer.
Three referrals and an answer, cached at every layer on the way back. The whole round trip typically takes tens of milliseconds and then doesn't happen again for hours.
That caching is the reason DNS scales to the entire internet on a comparatively tiny number of authoritative servers, and it's also the source of nearly every confusing DNS symptom.
Miss all of those and the query goes to a recursive resolver, usually your ISP's or something like a public resolver. The recursive resolver does the actual work on your behalf.
It asks a root server, which doesn't know your domain but knows who handles `.com`. It asks the `.com` servers, which don't know your IP but know your domain's authoritative nameservers. It asks those, and gets the answer.
Three referrals and an answer, cached at every layer on the way back. The whole round trip typically takes tens of milliseconds and then doesn't happen again for hours.
That caching is the reason DNS scales to the entire internet on a comparatively tiny number of authoritative servers, and it's also the source of nearly every confusing DNS symptom.
The Record Types That Matter
`A` maps a name to an IPv4 address, `AAAA` to IPv6. These are the ones that actually resolve to a machine.
`CNAME` aliases one name to another name. `www.example.com` pointing at `example.com` is the classic case. The rule that catches people: a CNAME cannot coexist with other records on the same name, which is why you can't put a CNAME on your root domain if you also need MX records there. Providers work around this with `ALIAS` or `ANAME` records that behave like a CNAME but resolve server-side.
`MX` routes mail, with priority numbers where lower wins. `TXT` holds arbitrary text and is where SPF, DKIM and domain verification records live.
`NS` records declare which nameservers are authoritative for the zone, and they're the ones you change at your registrar when moving DNS providers.
Those six cover almost everything you'll touch. `SRV` and `CAA` come up occasionally — the first for service discovery, the second to restrict which certificate authorities may issue for your domain.
`CNAME` aliases one name to another name. `www.example.com` pointing at `example.com` is the classic case. The rule that catches people: a CNAME cannot coexist with other records on the same name, which is why you can't put a CNAME on your root domain if you also need MX records there. Providers work around this with `ALIAS` or `ANAME` records that behave like a CNAME but resolve server-side.
`MX` routes mail, with priority numbers where lower wins. `TXT` holds arbitrary text and is where SPF, DKIM and domain verification records live.
`NS` records declare which nameservers are authoritative for the zone, and they're the ones you change at your registrar when moving DNS providers.
Those six cover almost everything you'll touch. `SRV` and `CAA` come up occasionally — the first for service discovery, the second to restrict which certificate authorities may issue for your domain.
TTL and So-Called Propagation
Every record carries a TTL — a number of seconds that resolvers are allowed to cache it. Set 3600 and a resolver that fetched your record keeps serving the old value for up to an hour after you change it, no matter what your dashboard says.
That's the whole of "propagation". Nothing is being pushed anywhere. Caches are expiring at different times because they were populated at different times.
Which leads to the one piece of DNS planning worth doing: lower the TTL *before* a migration, not during. Drop it to 300 a day ahead, make the change, then raise it back once things are stable. Change the record first and you're stuck waiting out the old TTL you were trying to avoid.
Some resolvers ignore very low TTLs and enforce a floor, and a few ignore long ones too. Treat TTL as a strong hint rather than a guarantee.
Negative caching is the detail nobody mentions: a failed lookup gets cached too, controlled by the zone's SOA record. Query a domain before its record exists and you can be stuck with the failure for longer than the record's own TTL.
That's the whole of "propagation". Nothing is being pushed anywhere. Caches are expiring at different times because they were populated at different times.
Which leads to the one piece of DNS planning worth doing: lower the TTL *before* a migration, not during. Drop it to 300 a day ahead, make the change, then raise it back once things are stable. Change the record first and you're stuck waiting out the old TTL you were trying to avoid.
Some resolvers ignore very low TTLs and enforce a floor, and a few ignore long ones too. Treat TTL as a strong hint rather than a guarantee.
Negative caching is the detail nobody mentions: a failed lookup gets cached too, controlled by the zone's SOA record. Query a domain before its record exists and you can be stuck with the failure for longer than the record's own TTL.
Debugging a Bad Resolve
`dig example.com` is the tool. It shows the answer, the TTL remaining and which server replied, and reading it takes about ten seconds once you know what you're looking at.
The key move is bypassing caches. `dig @1.1.1.1 example.com` asks a public resolver directly, and `dig +trace example.com` walks the full hierarchy from the root so you can see exactly which step returns something unexpected.
Compare that with your authoritative server: `dig @ns1.yourprovider.com example.com`. If the authoritative answer is right and the public one is wrong, you're waiting on a cache and there's nothing to fix. If the authoritative answer is wrong, the record itself is wrong.
On a developer machine, check the hosts file before anything else. An entry someone added during a local test three months ago overrides all of this silently, and it's the cause of a genuinely embarrassing share of "DNS is broken" reports.
Browsers keep their own cache too, separate from the OS one, which is why a curl request can succeed while the browser still fails.
The key move is bypassing caches. `dig @1.1.1.1 example.com` asks a public resolver directly, and `dig +trace example.com` walks the full hierarchy from the root so you can see exactly which step returns something unexpected.
Compare that with your authoritative server: `dig @ns1.yourprovider.com example.com`. If the authoritative answer is right and the public one is wrong, you're waiting on a cache and there's nothing to fix. If the authoritative answer is wrong, the record itself is wrong.
On a developer machine, check the hosts file before anything else. An entry someone added during a local test three months ago overrides all of this silently, and it's the cause of a genuinely embarrassing share of "DNS is broken" reports.
Browsers keep their own cache too, separate from the OS one, which is why a curl request can succeed while the browser still fails.
DNS and Your CDN
Put a site behind a CDN and DNS is how the routing happens. Your record points at the CDN rather than your origin, and the CDN's own DNS returns an edge address near the user.
That's why the same hostname resolves to different IPs in different countries. It isn't a misconfiguration, it's the point — anycast and geo-aware DNS route each visitor to a nearby node, as covered in our piece on how CDNs work.
The practical consequence is that pinging your domain tells you almost nothing about your server. You're measuring the distance to an edge node.
It also means DNS-level failover is only as fast as your TTL. A 300-second TTL means up to five minutes of traffic to a dead endpoint, which is why serious setups do failover at the load balancer rather than in DNS.
Cloudflare's learning centre on DNS is a good visual reference for the hierarchy if the text version isn't landing.
That's why the same hostname resolves to different IPs in different countries. It isn't a misconfiguration, it's the point — anycast and geo-aware DNS route each visitor to a nearby node, as covered in our piece on how CDNs work.
The practical consequence is that pinging your domain tells you almost nothing about your server. You're measuring the distance to an edge node.
It also means DNS-level failover is only as fast as your TTL. A 300-second TTL means up to five minutes of traffic to a dead endpoint, which is why serious setups do failover at the load balancer rather than in DNS.
Cloudflare's learning centre on DNS is a good visual reference for the hierarchy if the text version isn't landing.
DNS Over HTTPS and Privacy
Classic DNS is plaintext UDP, so anyone on the path can see every domain you look up and, in principle, tamper with the answers.
DNS over HTTPS and DNS over TLS both encrypt that traffic. Browsers now enable DoH by default in many configurations, which has a side effect worth knowing about: the browser may bypass your OS resolver entirely.
That breaks assumptions on corporate networks and in local development. A hosts file entry or an internal-only domain can stop working in one browser while the rest of the system resolves it fine, and the fix is a browser setting rather than anything system-level.
DNSSEC is the separate problem — it signs records so a resolver can verify they weren't tampered with. It doesn't encrypt anything, and the two are frequently confused.
If you run a public API, both matter for a practical reason: a resolver that can't validate your signed zone will fail closed, and a misconfigured DNSSEC rollover takes a domain offline more completely than almost any other mistake.
DNS over HTTPS and DNS over TLS both encrypt that traffic. Browsers now enable DoH by default in many configurations, which has a side effect worth knowing about: the browser may bypass your OS resolver entirely.
That breaks assumptions on corporate networks and in local development. A hosts file entry or an internal-only domain can stop working in one browser while the rest of the system resolves it fine, and the fix is a browser setting rather than anything system-level.
DNSSEC is the separate problem — it signs records so a resolver can verify they weren't tampered with. It doesn't encrypt anything, and the two are frequently confused.
If you run a public API, both matter for a practical reason: a resolver that can't validate your signed zone will fail closed, and a misconfigured DNSSEC rollover takes a domain offline more completely than almost any other mistake.
Things Worth Setting Up Once
Add a `CAA` record restricting which certificate authorities can issue certificates for your domain. It takes one line and closes a real attack path.
Set SPF, DKIM and DMARC properly even if you don't send email from the domain — a `v=spf1 -all` record on a non-sending domain stops it being used for spoofing, and DMARC reporting tells you when someone tries.
Keep TTLs moderate. Very long TTLs make emergencies slow and very short ones add latency and load for no benefit. Somewhere between 300 and 3600 covers most needs, and the right number depends on how often you actually change records.
Document which registrar holds the domain and which provider hosts the zone, because they're often different companies and the person who set it up may not be around. I've watched a team lose four hours to that question during an outage, and the fix was a wiki page nobody had written. While you're in there, it's worth confirming your TLS setup matches — our rundown of common request and response headers covers the ones that only behave correctly once DNS and certificates agree.
Set SPF, DKIM and DMARC properly even if you don't send email from the domain — a `v=spf1 -all` record on a non-sending domain stops it being used for spoofing, and DMARC reporting tells you when someone tries.
Keep TTLs moderate. Very long TTLs make emergencies slow and very short ones add latency and load for no benefit. Somewhere between 300 and 3600 covers most needs, and the right number depends on how often you actually change records.
Document which registrar holds the domain and which provider hosts the zone, because they're often different companies and the person who set it up may not be around. I've watched a team lose four hours to that question during an outage, and the fix was a wiki page nobody had written. While you're in there, it's worth confirming your TLS setup matches — our rundown of common request and response headers covers the ones that only behave correctly once DNS and certificates agree.
Frequently Asked Questions
How long does DNS propagation actually take?
It takes as long as the old record's TTL, because nothing is pushed anywhere — caches simply expire. If your TTL was 3600, some resolvers serve the old value for up to an hour after the change, and a few ignore short TTLs and hold on longer.
What is the difference between an A record and a CNAME?
An A record points a name directly at an IPv4 address. A CNAME points a name at another name, which then has to be resolved in turn. A CNAME can't coexist with other record types on the same name, which is why root domains usually need an A, ALIAS or ANAME record instead.
Why does my site work for others but not for me?
Almost always a cache on your machine — the browser's own DNS cache, the OS resolver cache, or a leftover hosts file entry. Check the hosts file first, then query a public resolver directly with dig to see what the rest of the world is getting. Our guide to [how CDNs work](/blog/what-is-a-cdn-how-content-delivery-networks-work) explains why the same hostname can legitimately resolve differently for different people.
How do I check what a DNS record actually resolves to?
Use dig with an explicit resolver, such as dig @1.1.1.1 example.com, to bypass local caching. Adding +trace walks the hierarchy from the root servers down so you can see precisely which step returns the wrong answer.
Should I lower my TTL before migrating a server?
Yes, and do it at least a day ahead so the long TTL has expired everywhere before you make the real change. Lowering it at the same time as the migration leaves you waiting out the old value anyway, which defeats the purpose.
Try ToolsFuel
23+ free online tools for developers, designers, and everyone. No signup required.
Browse All Tools