How DNS Works

The Domain Name System (DNS) translates a name such as www.example.com into an IP address that computers use to connect. A recursive resolver does the work for you: it asks the root servers, then the top-level domain servers, then the authoritative servers of the domain, and it stores the answer for later use. This usually takes a few milliseconds.

The resolution path

When you open www.example.com, these steps happen if nothing is cached:

1. Stub resolver. Your operating system has a small built-in client. It checks its own cache and the hosts file, then sends the question to the configured recursive resolver (usually from your router or provider, or a public one).
2. Recursive resolver. It checks its cache. If it has no answer, it starts from the top and asks questions until it finds the final answer.
3. Root servers. The resolver asks a root server for www.example.com. The root does not know the address, but it replies with the servers responsible for .com.
4. TLD servers. The .com servers do not know the address either, but they reply with the name servers of example.com (the NS records).
5. Authoritative servers. The name server of the domain holds the real records and returns the A or AAAA record for www.example.com.
6. The resolver returns the answer to the stub resolver, stores it in its cache, and the browser connects.

You can follow this chain for any domain with our DNS checker.

Caching and TTL

Every DNS record has a TTL (time to live), a number of seconds that tells resolvers how long they may keep the answer. A TTL of 3600 means one hour. Caching makes DNS fast and reduces load on the authoritative servers, but it also means that a change does not appear everywhere at once. Caches exist at several places: the browser, the operating system, the router and the recursive resolver.

Resolvers also cache negative answers, for example "this name does not exist" (NXDOMAIN), for a time given in the SOA record.

Common record types

Type	Purpose	Example value
A	Maps a name to an IPv4 address	192.0.2.10
AAAA	Maps a name to an IPv6 address	2001:db8::10
CNAME	Alias from one name to another name. It cannot exist at the zone apex next to other records.	www.example.com → example.com
MX	Mail servers for the domain, with a priority (lower number is tried first)	10 mail.example.com
NS	Authoritative name servers of the zone	ns1.example.com
TXT	Free text; used for SPF, DKIM, DMARC and domain verification	"v=spf1 mx -all"
SOA	Start of authority: primary server, admin contact, serial number and timers	ns1.example.com hostmaster.example.com 2026110401 ...
CAA	Which certificate authorities may issue certificates for the domain	0 issue "ca.example.net"
SRV	Host and port of a specific service	10 5 5060 sip.example.com
PTR	Reverse lookup: maps an IP address back to a name	10.2.0.192.in-addr.arpa → host.example.com

The correct MX, SPF and DKIM records are important for email delivery. Use our mail and blacklist tool to check a mail server, and see whether its IP address is listed on spam blocklists.

What DNS propagation really is

"DNS propagation" is a common name for the time until all caches in the world have dropped the old answer and fetched the new one. Nothing is pushed across the internet. The authoritative server has the new data immediately; resolvers simply keep the old data until its TTL expires. So the maximum delay for a changed record is about the old TTL, not the new one.

Changing name servers at the registrar is slower, because the NS records in the TLD zone usually have a TTL of one to two days. During that time some users reach the old servers and some reach the new ones. You can check the delegation of a domain with the WHOIS lookup, and the records themselves with the DNS checker.

How to make a change spread fast

1. At least one old TTL period before the change (for example 24 hours if the TTL is 86400), lower the TTL of the record to a small value such as 300 seconds.
2. Wait until the old TTL has passed, so that all caches hold the short-lived version.
3. Make the change. Resolvers now ask again within about 5 minutes.
4. Check the result from several locations with a DNS checker.
5. After everything works, raise the TTL again to reduce query load.

SOA serial and secondary servers

Most domains use at least two authoritative servers. One is the primary, and the others are secondaries that copy the zone from it by a zone transfer (AXFR or IXFR). The SOA record controls this:

• Serial: a version number. A secondary transfers the zone when the serial on the primary is higher than its own. A common format is date plus counter, such as 2026110401. If you edit a zone and forget to raise the serial, secondaries keep serving the old data.
• Refresh: how often a secondary checks the serial.
• Retry: how long a secondary waits before trying again after a failed check.
• Expire: after this time without contact, a secondary stops answering.
• Minimum (negative TTL): how long resolvers cache "does not exist" answers.

If a domain returns different answers from different name servers, a stale secondary is a likely cause. Compare the serial numbers of all NS servers.

Anycast resolvers

Public resolvers such as those run by large providers use anycast: the same IP address is announced from many data centers, and the network routes each query to the nearest one. This gives low delay and resilience. Each location has its own cache, which is why two people using the same resolver address can briefly see different answers after a change. The same technique is used by the root servers and by many authoritative DNS services.

For related basics, read what an IP address is and the OSI model, where DNS sits at the application layer.