Why names need translating
People remember names such as example.com far more easily than strings of digits, but the network delivers data using numeric addresses. Something has to translate between the two, and that job belongs to the domain name system, usually shortened to DNS.
DNS is often called the phone book of the internet. The comparison is useful but incomplete. There is no single book. Instead, the information is spread across a very large number of servers run by different organizations, arranged in a hierarchy so that no one machine has to know everything.
The pieces involved
A few terms help in following a lookup.
- Stub resolver: a small piece of software in your device’s operating system that asks for answers on your behalf.
- Recursive resolver: a server that does the searching for you. It is usually operated by your internet provider, though some people choose a public alternative. It remembers answers for a while.
- Root servers: the starting point of the hierarchy. They do not know the address of most sites, but they know where to find the servers responsible for each top-level domain, such as
.comor.org. - Top-level domain (TLD) servers: these know which name servers are responsible for each name registered under their ending.
- Authoritative name servers: these hold the actual records for a domain and give the final answer. The site owner, or the company hosting their DNS, controls them.
A lookup, step by step
Suppose you visit www.example.com, a reserved example name.
- Your browser checks its own memory for a recent answer. If it finds one, the process stops here.
- If not, your device checks its own cache, then asks the recursive resolver.
- If the resolver does not have a saved answer, it asks a root server where to find
.cominformation. - The root server points to the
.comservers. The resolver asks them aboutexample.com. - The
.comservers reply with the names of the authoritative servers for that domain. - The resolver asks one of those servers for
www.example.com, and receives the numeric address. - The resolver returns the answer to your device and saves it for later.
The whole exchange typically takes a small fraction of a second, and most lookups skip several steps because some part of the chain already has the answer saved.
Record types
A DNS answer is a record, and there are different kinds for different jobs. A few common ones:
- A and AAAA: link a name to an IPv4 or IPv6 address respectively. The older and newer address formats are explained in the articles on IP addresses and IPv6 addresses.
- CNAME: says that one name is an alias for another name. Sites often use this to point a name at a hosting service.
- MX: identifies the mail servers for a domain, which is how email delivery knows where to send messages.
- TXT: holds text, often used to prove ownership of a domain or to publish email-authentication settings.
- NS: lists the authoritative name servers for a domain.
Caching and time to live
Every record carries a time to live, or TTL, measured in seconds. It tells resolvers how long they may reuse an answer before asking again. Caching reduces the load on the system and speeds up browsing, since popular names do not need to be looked up from scratch every time.
The trade-off is that changes spread gradually. If a site owner moves their site to a new server and updates the record, resolvers that saved the old answer may keep using it until its TTL runs out. This is why people sometimes say a DNS change can take “hours” or even longer to propagate. The actual delay depends on the TTL values involved and varies. Site owners often lower the TTL ahead of a planned move to make the switch quicker.
Why DNS matters for speed and reliability
Because a lookup usually happens before a page can begin loading, a slow resolver can make every first visit to a site feel sluggish. Large sites commonly use several authoritative servers in different locations so that one failure does not take the site offline. Content delivery networks also use DNS to steer users toward a nearby server, handing out different addresses depending on where the request appears to come from.
When DNS fails, the effects can look dramatic. The servers hosting a site might be running perfectly well, but if the lookup cannot be completed, browsers report that the site cannot be found. Past cloud outages have sometimes involved DNS problems for this reason, since so many services depend on it.
Privacy and security
Traditional DNS queries are sent without encryption, which means the networks between you and the resolver can see which names you look up. The names you look up are visible even if the pages themselves are protected by HTTPS. Options such as DNS over HTTPS and DNS over TLS encrypt the query to your resolver. They protect the lookup in transit but do not hide your activity from the resolver itself, and the destination address will still be visible to your internet provider.
DNS can also be abused. In an attack sometimes called cache poisoning, false answers are inserted so that a name points to the wrong place. A security extension called DNSSEC lets records be digitally signed so that resolvers can detect tampering, although it has not been adopted everywhere.
Because lookups are so central, some networks use DNS to filter content: a resolver can refuse to answer for known malicious names. Families and organizations sometimes use this as a light layer of protection, but it is not a substitute for other safeguards.
A practical troubleshooting note
If one site fails to load but others work, DNS is one possible cause, though far from the only one. Trying a different network, or restarting your router, can help separate a local problem from a wider one. Clearing your device’s DNS cache is another option. Whether any of these helps depends on where the failure actually is.