DNS (the Domain Name System) translates a domain name into an IP address through a short chain of lookups. Your device asks a recursive resolver for the address. If the resolver does not already have the answer cached, it asks a root server, which refers it to the servers for the top-level domain, such as .com. Those servers refer it to the domain’s authoritative nameservers, which return the actual record. The resolver caches that answer for as long as the record’s TTL (time to live) allows and hands it back to your device, which then connects to the website. The whole walk usually takes a fraction of a second, and most lookups skip most of it because of caching.
Why Domain Names Need Translating
Computers on the internet find each other by IP address: a numeric label such as 192.0.2.10 in IPv4, or a longer hexadecimal address in IPv6. People cannot remember those numbers, and the numbers change whenever a site moves to a new host. DNS solves both problems. It lets you publish a stable, readable name and change the address behind it whenever you need to, without telling anyone.
DNS is distributed by design. No single server knows every address. Instead, responsibility is delegated down a hierarchy, and each level only knows who is responsible for the level below it. Translating a domain name is the process of following those delegations until you reach the server that holds the answer.
How DNS Reads a Domain Name
DNS reads a name from right to left. In www.example.com, the rightmost part is an invisible root, written as a trailing dot. Next comes the top-level domain, com. Then the second-level domain, example, which is the part a registrant registers. Finally comes www, a subdomain (a name the domain holder creates under their own domain). Each dot marks a point where responsibility can be handed to a different set of servers, and the lookup follows those hand-offs in the same right-to-left order.
The Servers That Take Part in a Lookup
Four kinds of DNS server take part in a typical lookup. The stub resolver is the small DNS client built into your operating system; it does not resolve names itself but passes questions to a recursive resolver. The recursive resolver does the work of chasing referrals; it is usually run by your internet provider, your employer, or a public service such as Google Public DNS or Cloudflare’s 1.1.1.1. The root servers sit at the top of the hierarchy and know which servers handle each top-level domain. The TLD servers, run by the registry for each extension, know which nameservers are authoritative for each registered domain. And the authoritative nameservers, run by whoever hosts the domain’s DNS, hold the domain’s actual records.
How a DNS Lookup Resolves, Step by Step
The walk-through below follows a request for www.example.com from a browser that has never visited the site.
Step One: The Device Checks Its Own Caches
Before anything leaves your computer, the browser checks its own short-lived DNS cache, and the operating system checks its cache and its local hosts file. If a fresh answer is found, the lookup ends here. If not, the stub resolver sends the question, “What is the IPv4 address (A record) for www.example.com?”, to the configured recursive resolver.
Step Two: The Recursive Resolver Takes the Question
The recursive resolver checks its own cache, which is shared by every user of that resolver. A popular name is often already there. If it has nothing useful, it starts at the top of the hierarchy. In practice, a busy resolver almost always has the .com servers cached already and skips straight to step four, but the full path is worth understanding.
Step Three: A Root Server Refers the Resolver to the TLD
The resolver asks a root server about www.example.com. The root server does not know the answer and does not need to. It replies with a referral: the list of nameservers responsible for .com. The root is served by thirteen named server identities, lettered A through M and run by a dozen independent organizations, each copied to many sites around the world through anycast (a routing method that lets many servers share one address, so queries reach the nearest copy).
Step Four: The TLD Servers Refer the Resolver to the Domain’s Nameservers
The resolver now asks a .com server, operated for the registry by Verisign. That server holds the delegation for every .com name: a set of NS (nameserver) records saying which servers are authoritative for example.com, plus glue records (the IP addresses of those nameservers, when they sit inside the domain itself). This delegation is the part of DNS that your registrar controls. When you change nameservers at your registrar, the registrar updates this record at the registry.
Step Five: The Authoritative Nameserver Answers
The resolver asks one of example.com’s authoritative nameservers for the A record for www.example.com. That server holds the domain’s zone (the full set of DNS records for the domain) and returns the answer with a flag marking it as authoritative. If www is a CNAME (an alias pointing to another name), the resolver follows the alias and repeats the process for the target name until it reaches an address.
Step Six: The Answer Is Cached and Returned
The resolver stores the answer in its cache for the number of seconds set in the record’s TTL, then returns it to your stub resolver, which passes it to the browser. The browser opens a connection to that IP address and requests the page. The next user of the same resolver who asks for www.example.com gets the cached answer in step two, without any of the steps in between.
| Stage | Who answers | What it knows | What it returns |
|---|---|---|---|
| Local cache | Browser and operating system | Recent answers on this device | A cached address, or nothing |
| Recursive resolver | Internet provider, employer or public DNS service | Cached answers for all its users | A cached answer, or it begins the walk |
| Root server | Root server operators | Which servers run each top-level domain | A referral to the TLD servers |
| TLD server | The registry for the extension | Which nameservers serve each registered domain | A referral to the domain’s nameservers |
| Authoritative nameserver | The domain’s DNS host | The domain’s actual records | The final answer, with its TTL |
Recursive and Iterative Queries
Two kinds of question appear in that walk. Your device sends a recursive query: it asks the resolver for a final answer and expects the resolver to do whatever work is needed. The resolver then sends iterative queries to the root, TLD and authoritative servers: each of those servers answers only what it knows, either with the record or with a referral to a server closer to it. That division of labor is what lets the root and TLD servers handle enormous volumes of traffic. They never chase answers on anyone’s behalf.
Caching, TTL and the Myth of Propagation
Caching is what makes DNS fast, and TTL is what controls caching. Every record carries a TTL in seconds. A resolver that has cached a record may keep using it until the TTL runs out, even if the record has changed at the authoritative server in the meantime. Resolvers also cache negative answers, so a lookup for a name that did not exist can be remembered for a while after the name is created.
This is why DNS changes seem to “propagate” slowly. Nothing is actually spreading across the internet. Resolvers around the world are simply holding older answers until their cached copies expire. The practical lesson is to lower the TTL on a record a day or two before you plan to change it, make the change, and raise the TTL again afterward. Nameserver changes are slower still, because the delegation records held at the TLD level often carry TTLs of a day or two, and that is outside your DNS host’s control.
Where Your Registrar and DNS Host Fit
Two separate accounts control how your domain name translates. The registrar account (our guide to how domain name registrars work covers the registrar’s role) controls the delegation at the registry, which decides which nameservers are authoritative. The DNS hosting account, which may be at the same company or a different one, controls the records on those nameservers. Whoever controls either account controls where your domain sends visitors and email. Our guide to nameservers and DNS records explains the record types, including A, AAAA, CNAME, MX and TXT, and how to edit them.
Where DNS Resolution Can Be Attacked
Each step in the lookup is a point where an attacker can substitute a false answer. The most effective attacks do not touch DNS servers at all; they log in to the registrar or DNS hosting account and change the nameservers or records, so the authoritative answer itself becomes malicious. That is DNS hijacking, and it is hard to spot because every server in the chain is behaving correctly.
These attacks can be brief and still do damage. In a study of state-sponsored campaigns, the attacker’s resolution lasted at most one day for 51% of hijacked domains, according to Akiwate and colleagues at ACM IMC 2022. Short windows are enough to obtain a certificate and collect passwords. After a wave of such hijackings, the U.S. Department of Homeland Security issued CISA Emergency Directive 19-01 in January 2019, requiring federal agencies within ten business days to audit their public DNS records, change passwords on accounts that can modify DNS, add multi-factor authentication and monitor Certificate Transparency logs. Those four actions remain a sound baseline for any organization.
How DNSSEC Protects the Translation
DNSSEC (Domain Name System Security Extensions) adds digital signatures to DNS records. Each level of the hierarchy vouches for the keys of the level below it, so a validating resolver can confirm that an answer really came from the domain’s authoritative servers and was not altered on the way. A forged answer fails validation and is discarded.
Adoption is uneven. As of October 2021, about 92.2% of top-level domains in the root zone were signed, but only about 5% of second-level domains were, according to the European Commission Joint Research Centre. On the other side of the exchange, some 30% of internet users sit behind resolvers that validate DNSSEC, according to Geoff Huston of APNIC. DNSSEC protects against forged answers in transit; it does not protect against an attacker who logs in to your registrar and changes the delegation. Encrypted transports such as DNS over HTTPS and DNS over TLS solve a different problem again: they hide your queries from eavesdroppers between your device and the resolver.
Checking a DNS Translation Yourself
You can watch the lookup happen. On macOS or Linux, the command dig +trace www.example.com walks the hierarchy from the root and prints each referral, which is the clearest way to see the steps above in action. The nslookup command, available on Windows, queries a resolver directly and is useful for checking what a particular resolver currently has cached. Comparing answers from two public resolvers is a quick way to tell whether a change is still waiting on caches. For changes over time, a domain name DNS history lookup shows how a domain’s records and nameservers have changed, which is often the first evidence in a hijacking investigation.
How DNAccess Helps
Because DNS translates your domain name for every visitor and every email, an unauthorized change to your nameservers or records is one of the most damaging things that can happen to a business online. Our DNShield domain name monitoring watches registration and DNS data for changes and alerts you promptly, so an unauthorized change is caught before customers and email partners notice it. If your domain has already been redirected or taken, our stolen domain name recovery team works to restore control. The rest of our Domain Name Basics guides explain the other moving parts in plain English.