The answer you see in your browser almost always comes from a recursive DNS server, not the domain's own authoritative server. DNS, the Domain Name System, matches domain names like example.com to the IP addresses computers need to connect.
A recursive server asks other servers on your behalf and returns the result. An authoritative server holds the official records for a specific domain. Knowing which one answered helps you fix site, email, and migration problems faster.
Table of Contents
- What does each server do?
- How does a lookup travel between them?
- Why does this matter for your website?
- How can you tell which server gave the answer?
- What breaks at each layer?
- Frequently Asked Questions
What does each server do?
A recursive DNS server works for the visitor. Your computer, phone, or office network sends it one question, such as where is example.com, and it chases the full answer. Internet providers run these resolvers, and public options include services people set in their Wi-Fi or device settings. An authoritative DNS server works for the domain owner.
It stores the official records for a domain, such as the address record that points to a web host and the mail records that direct email. When it answers for a name it controls, its answer is final. A helpful comparison is a librarian and an author. The recursive server is the librarian who tracks down a fact from many shelves. The authoritative server is the author who defines what is true for that title.
How does a lookup travel between them?
A typical lookup happens in four quick steps. Your browser asks the configured recursive server first. If that server has a fresh cached answer, it replies at once without asking anyone else. If the answer is not cached, the recursive server walks down the hierarchy.
It asks a root server where to find the extension, then asks that extension server where to find the domain, then asks the domain's authoritative server for the exact record. Each step returns a referral until the authoritative answer arrives. The recursive server then passes that final answer back to your device and saves a copy for a set time. That save time is controlled by TTL, or time to live, a number set in the authoritative record. Short TTLs refresh faster, while long TTLs reduce repeated lookups.
Why does this matter for your website?
It matters because only authoritative changes alter your site. Moving a WordPress or Drupal site, switching hosts, adding a content delivery network, or fixing email delivery all require edits at the authoritative DNS provider. Edits made anywhere else will not move traffic. It also matters because visitors feel recursive behavior.
A campaign landing page may load for you but fail for some visitors if their resolver still holds an old cached address. Front-end and project teams often see this as broken deploys, missing images, or mixed test results right after a move. Use this split to plan changes. Lower the TTL at the authoritative server a day or more before a planned move so resolvers cache the old address briefly. Make the move, confirm the authoritative answer is correct, then raise the TTL again for stable performance.
How can you tell which server gave the answer?
Check the authoritative record when you want the source of truth. Your DNS provider dashboard, domain registrar, or host panel usually labels the authoritative name servers and zone records.
What you see there is what the domain publishes to the world. Check a recursive answer when you want what visitors receive. These checks show caching and propagation from the visitor side.
- Run a direct query against the authoritative server for the domain, then repeat the same query against your default resolver and compare results.
- Use lookup tools that show response time, TTL remaining, and which server replied, such as dig on Mac and Linux or nslookup on Windows.
- Test from more than one network, such as office Wi-Fi, mobile data, and a public resolver, after DNS changes.
What breaks at each layer?
Authoritative problems affect everyone. A wrong address record sends all visitors to the wrong server. A missing mail record blocks delivery. An expired domain or broken delegation leaves resolvers with no valid path to follow. Recursive problems affect some people.
A resolver may serve stale data until TTL expires. It may block a new record through filtering, or return an error during an outage even though the site itself is online. Clearing local cache, waiting out TTL, or testing another resolver can confirm this pattern. Keep responsibility clear during an incident. Confirm the authoritative records first, then check major resolvers for cached or filtered results. Share both answers with support so the fix reaches the right layer.
Frequently Asked Questions
Does changing my computer's DNS setting change my website for everyone?
No. It changes only which recursive server your computer asks. To change the site for all visitors, edit the authoritative records at the domain's DNS provider.
Why do DNS changes take time to appear?
Recursive servers cache prior answers until TTL expires. Each resolver refreshes on its own schedule, so some visitors see the new address before others.
Who controls TTL?
The domain owner controls it through the authoritative record. Lower it before moves for faster updates, then raise it afterward to improve caching and lookup speed.
