DNS (Domain Name System) is the service that translates names such as example.com into IP addresses. You use it hundreds of times a day without noticing: every page, every app, every email goes through one or more DNS queries. When DNS stops working, it feels as if "the Internet is down", even though the connection is perfectly fine.
A distributed, hierarchical database
DNS is not a single list stored in one place. It is a tree structure, read from right to left:
- at the top is the root, represented by an implicit trailing dot (example.com.);
- below it are the top-level domains (TLDs), such as .it, .com, .org;
- then registered domains, such as example.com;
- and finally any subdomains, such as www.example.com or mail.example.com.
Each level delegates authority over a portion of the tree to the next one. The operator of .com knows which servers are responsible for example.com, but does not know the addresses of its subdomains: only the domain's authoritative server knows those.
The players in resolution
| Component | What it does |
|---|---|
| Stub resolver | The part of the operating system that asks the question |
| Recursive resolver | The server that looks up the answer on your behalf (your ISP's, your router's or a public one) |
| Root server | Points to the servers that handle each TLD |
| TLD server | Points to the servers that are authoritative for a domain |
| Authoritative server | Holds the domain's records and gives the final answer |
The path of a query
Suppose you want to open www.example.com and nobody has the answer cached:
- The computer asks the configured resolver (often the router, which in turn forwards to the ISP).
- The resolver asks a root server: "who handles .com?". The root replies with the list of .com servers.
- The resolver asks a .com server: "who handles example.com?". It receives the names of the domain's authoritative servers.
- The resolver asks the authoritative server for the address of www.example.com and gets the answer.
- The resolver returns it to the computer and stores it in its cache.
All of this usually takes a few tens of milliseconds. Subsequent queries are even faster, because intermediate and final answers stay in memory.
Caching and TTL
Every DNS record has a TTL (Time To Live), expressed in seconds, which tells a resolver how long it may keep the record cached before asking again. A TTL of 3600 means one hour.
Caching happens at several levels: in the browser, in the operating system, in the router, in the ISP's resolver. It is what makes DNS fast, but it is also why changes are not instant.
When you change a website's IP address, anyone holding the old record in cache keeps using it until the TTL expires. The famous "DNS propagation" is not an active process: it is simply waiting for caches to expire.
A practical tip for migrations
If you need to move a site to a new server:
- a few days beforehand, lower the TTL of the relevant record, for example to 300 seconds;
- wait at least for the old TTL to pass, so caches have picked up the new short value;
- change the address: within minutes almost everyone will see the new server;
- once the migration is done, raise the TTL back to a higher value.
Negative answers ("this name does not exist") are cached too, for a time specified in the zone's SOA record. If you query a subdomain before creating it, you may have to wait before you see it working.
Which resolver to use
The resolver sees the list of sites you visit and partly determines how fast they load. Typical options are your ISP's, a public one, or one you run yourself on the local network. Modern resolvers also support encrypted protocols, such as DNS over HTTPS and DNS over TLS, which prevent anyone on the network from reading or tampering with queries on their way to the resolver.
Diagnosing DNS problems
Some typical symptoms and first checks:
- The site will not open, but its IP address does: the problem is DNS, not the connection.
- The site opens on one device but not another: probably different caches or different resolvers.
- After a change you still see the old site: check the TTL and flush the local cache.
The most useful tools are nslookup, available on every system, and dig on Linux and macOS. With dig www.example.com you see the answer and the remaining TTL; with dig @server www.example.com you query a specific server, for example the authoritative one directly, bypassing caches.
In short
- DNS is a hierarchical, distributed database: root, TLDs, domains and subdomains.
- The recursive resolver does the lookup work and caches the answers.
- The TTL sets how long caching lasts: "propagation" is just waiting for it to expire.
- Before changing an important record, lower its TTL a few days in advance.
- With dig and nslookup you can query specific servers and find where a problem starts.
