How DNS works: from a name in the address bar to an IP address

Computers find each other by numbers (IP addresses), but people remember names. The Domain Name System (DNS) is the global directory that turns www.example.com into an address, and it is involved in almost everything you do online.

A lookup, step by step

When your browser needs the address for www.example.com, this is roughly what happens.

1. The browser and operating system check their own caches. If either remembers a recent answer, it is used and nothing else happens.
2. The request goes to a recursive resolver. That is a server (usually your internet provider's, or a public one you chose) whose job is to find the answer and remember it.
3. The resolver checks its cache. Many popular names are answered here.
4. If not, it asks a root server where to find .com. The root does not know the address; it points to the servers responsible for .com.
5. It asks a .com (top-level domain) server about example.com. That server replies with the name servers responsible for the domain.
6. It asks the domain's authoritative server for www.example.com, and receives the real answer: an address and a TTL.
7. The resolver caches the answer for the TTL and returns it to your computer, which connects.

Each level only knows who to ask next. No single server holds the whole directory, which is why the system scales to the whole internet.

Caching and TTL

Every answer carries a TTL, the number of seconds anyone may reuse it. Caches at every level obey it. This speeds things up enormously, and it explains a classic frustration: when you change a record, nothing is pushed out. Resolvers worldwide keep serving the old answer until their copies expire, so the change appears gradually, up to the old TTL.

Practical consequence: before a planned move (a new server, a new mail provider), lower the TTL a day or two ahead, make the change, then raise it again. A short TTL means faster changes but more lookups.

The record types you will use

The address 203.0.113.10 above comes from a range reserved for documentation. Never use a real address in an example.

Checking records yourself

dig +short www.example.com A
dig +short example.com MX
dig +short example.com TXT
nslookup -type=MX example.com

dig is common on Linux and macOS, and nslookup is available on Windows as well. Asking a specific resolver (dig @8.8.8.8 example.com) shows what that resolver sees, which helps when a change appears for some people and not others.

Common mistakes

• A CNAME at the root of the domain. It is not allowed alongside the records the root must have. Use an A or AAAA record, or your provider's alias feature.
• Forgetting the dot. In some zone files, a name without a trailing dot is treated as relative and gets the zone name appended, giving example.com.example.com.
• Changing records at the wrong place. The records live at whoever your name servers say they do. Editing a zone at one provider while the registrar still points at another changes nothing.
• Leaving old records behind. A record pointing at a decommissioned service can be taken over by someone else. Remove what you no longer use.
• Expecting an instant change. Allow for the TTL.
• Mail records missing. E-mail delivery depends on correct MX and TXT records. When mail misbehaves after a DNS change, check these first.

Beyond lookup

Plain DNS is not encrypted or authenticated by default. DNSSEC adds signatures so answers can be checked, and DNS over HTTPS or TLS encrypts the question between you and your resolver. Both are worth knowing when you work on security.