How DNS Works
The Domain Name System (DNS) is the internet's phone book: it translates human-friendly names
like example.com into the IP addresses machines use to connect. When you open a
site, a recursive resolver walks a hierarchy - root server, then TLD
server, then the domain's authoritative name server - to find the right
address, caches the answer for its TTL, and returns it to your browser. This guide explains that
flow, the common record types, and why changes take time to propagate.
The lookup flow: resolver → root → TLD → authoritative
A single DNS resolution typically follows these steps:
- Stub resolver. Your device asks its configured recursive resolver (your ISP's, or a public one like Cloudflare's
1.1.1.1or Google's8.8.8.8) for the address ofwww.example.com. - Cache check. If the resolver already has a valid (non-expired) answer cached, it returns it immediately and the process stops here.
- Root servers. Otherwise the resolver asks a root server, which does not know the address but replies with a referral to the servers for the relevant top-level domain (TLD), e.g.
.com. - TLD servers. The resolver asks the
.comTLD servers, which refer it to the authoritative name servers listed forexample.com. - Authoritative servers. The resolver queries the domain's authoritative name server, which returns the actual record (e.g. an A record with the IP).
- Answer & cache. The resolver caches the answer for its TTL and returns the IP to your device, which then opens a connection.
You can watch each layer respond using our DNS Lookup tool, which queries records directly for any domain.
Common DNS record types
A DNS zone holds different record types, each serving a specific purpose:
| Record | Purpose | Example value |
|---|---|---|
A |
Maps a name to an IPv4 address | 203.0.113.10 |
AAAA |
Maps a name to an IPv6 address | 2001:db8::10 |
CNAME |
Aliases one name to another canonical name | www → example.com |
MX |
Directs email to mail servers (with priority) | 10 mail.example.com |
TXT |
Arbitrary text; used for SPF, DKIM, DMARC, verification | v=spf1 include:_spf.example.com -all |
NS |
Delegates a zone to its authoritative name servers | ns1.example.com |
SOA |
Start of authority: zone metadata, serial, refresh timers | ns1.example.com hostmaster.example.com … |
For a deeper look at every record type and its fields, read DNS Record Types Explained.
TTL and caching
Every record carries a TTL (Time To Live) in seconds that tells resolvers how long they may keep the answer in cache before asking again. Caching is what makes DNS fast and resilient: a popular name is answered from a nearby cache in milliseconds instead of walking the full hierarchy every time.
TTL is a trade-off. A short TTL (such as 300 seconds) lets you change records quickly but increases query volume; a long TTL (such as 86,400 seconds / one day) cuts load and survives upstream outages but slows updates. A common practice before a planned migration is to lower the TTL a day in advance so the cutover propagates in minutes rather than hours.
Why propagation takes time
"DNS propagation" is a slightly misleading phrase - nothing is actively pushed across the internet. When you publish a new record, resolvers around the world keep serving the previously cached value until its TTL expires, then independently fetch the new one. Because each resolver cached the record at a different moment, the change appears to spread gradually and can take anywhere from a few minutes to 48 hours, governed mainly by the old TTL.
To check whether a change has rolled out across different locations, use our DNS Propagation Checker, which queries multiple resolvers so you can see who is still serving the old answer.
DNSSEC: authenticating DNS answers
DNSSEC (the DNS Security Extensions, defined in
RFC 4033-4035)
lets a resolver verify that a DNS answer genuinely came from the zone's owner and was
not altered in transit, providing origin authentication and
data integrity. It works by signing records: each record set is covered
by an RRSIG signature, the public key that validates it is published as a
DNSKEY, and a DS record in the parent zone holds a hash of the
child's key - so a resolver can follow a chain of trust from the queried
domain up through its parent zones to the root, whose key is a known trust anchor. If any
signature fails to validate, the resolver treats the answer as bogus and refuses to return
it, which blocks cache-poisoning and spoofing attacks. Note that DNSSEC does
not encrypt your lookups - it only proves they are authentic; keeping the queries
themselves private is the job of DNS over HTTPS (DoH) and DNS over TLS (DoT).
Related tools & reading
- DNS Lookup - query A, AAAA, MX, TXT, NS, SOA and more for any domain.
- DNS Propagation Checker - see if a change has reached resolvers worldwide.
- DNS Record Types Explained - the full record reference.
- Back to the Learning Center
Frequently asked questions
What happens when I type a domain into my browser?
Your device asks a recursive resolver (often run by your ISP or a public provider like 1.1.1.1 or 8.8.8.8) to find the IP for the domain. If the answer is not cached, the resolver queries a root server, then the TLD server for the extension (such as .com), then the authoritative name server for the domain, which returns the IP. The resolver caches the answer and hands it to your browser, which then connects to that IP.
What is a DNS TTL and why does it matter?
TTL (Time To Live) is a value in seconds attached to each DNS record that tells resolvers how long they may cache it. A short TTL (e.g. 300 seconds) means changes propagate quickly but generates more queries; a long TTL (e.g. 86400 seconds) reduces load and improves resilience but makes updates slower to take effect. Lower the TTL a day before a planned change so the switch happens fast.
Why does DNS propagation take so long?
There is no central push that updates the whole internet at once. After you change a record, resolvers worldwide keep serving the old cached value until its TTL expires, then fetch the new one independently. Because different resolvers cached the record at different times, the change appears to "roll out" gradually - anywhere from minutes to 48 hours depending on the previous TTL.
What is the difference between a recursive and an authoritative DNS server?
A recursive resolver does the legwork of finding an answer on your behalf, querying other servers and caching the result. An authoritative name server is the source of truth for a specific domain - it holds the actual records the domain owner published and answers directly for that zone, without referring the query elsewhere.
Is DNS encrypted?
Classic DNS over port 53 is sent in plaintext, so anyone on the path can see your lookups. Modern encrypted transports fix this: DNS over HTTPS (DoH, RFC 8484) and DNS over TLS (DoT, RFC 7858) wrap queries in TLS so they are private and tamper-resistant. Many browsers and operating systems now enable DoH by default.
How this tool works: This tool runs in your browser and on our server in real time. Depending on the tool, results are computed directly from the input you provide or retrieved from live, authoritative data sources at the moment you run a lookup. We do not sell your data, and your lookups are kept private — any history shown here is stored only on your device.