What DNS does for websites and email
DNS, the Domain Name System, is the distributed system that maps domain names to the data computers need to reach them. Its most common job is turning a name such as example.com into an IP address. Before your browser can connect to a website, it asks DNS where that name points.
DNS also tells mail servers where to deliver email for a domain, through MX records, and publishes text records used for domain verification and email authentication. One lookup process serves all of these, which is why a single DNS mistake can take down a website and its email at the same time.
Queries normally travel over port 53 using UDP, with TCP used for large responses. The protocol is defined in RFC 1034 and RFC 1035 and has been extended many times since.
The recursive resolver queries root, TLD, and authoritative nameservers sequentially to return the target IP to the browser.
The parts that answer a DNS lookup
A lookup passes through a few distinct roles. When something goes wrong, most of the work is finding out which one gave you the answer.
- The stub resolver is the small DNS client built into your operating system. It forwards queries to a recursive resolver and often keeps a short cache.
- A recursive resolver does the searching on your behalf. It is usually run by your ISP, your employer, or a public service such as Cloudflare (1.1.1.1), Google (8.8.8.8) or Quad9 (9.9.9.9).
- Authoritative nameservers hold the records for a zone and give the definitive answer for it. The root servers, the servers for each top-level domain (TLD) and your DNS host's servers are each authoritative for their own part of the name.
- Records are the data itself. Each one has a name, a type such as A, MX or TXT, a value, and a TTL that says how long it may be cached.
- Caches in browsers, operating systems, routers and recursive resolvers keep recent answers, so repeat lookups are answered without asking the authoritative servers again.
How the DNS hierarchy splits the work
No single server knows every record. DNS is divided into zones arranged as a tree, and each level hands the next level down to other nameservers using NS records, a step called delegation.
The root zone delegates com to the .com servers, which delegate example.com to the nameservers its owner chose. Those servers answer for example.com and every name under it, such as www.example.com, unless part of it is delegated again.
When a resolver has nothing cached, it follows these referrals from the root down until it reaches a server that holds the answer. It caches each referral as well, so its next lookup under .com can skip the root.
Why caching shapes how DNS behaves
Every record carries a TTL (time to live) in seconds. Resolvers and devices may reuse a cached answer until its TTL runs out, and then they must ask again.
Caching keeps DNS fast: a cached answer needs one short round trip to the resolver, while an uncached one can need several trips to servers around the world. It is also why changes are not instant.
After you edit a record, people keep getting the old value until their resolver's cached copy expires. That delay is what "DNS propagation" usually refers to.
What happens when DNS stops working
Almost every connection starts with a lookup, so DNS problems look like outages of whatever depends on them. The server can be healthy while nobody can find it.
- A website shows a "server not found" error when its name does not resolve. Common causes are a deleted record, an expired domain, or wrong nameservers at the registrar.
- Email bounces or stops arriving when MX records point to the wrong servers. It is also more likely to be rejected or filtered as spam when SPF, DKIM or DMARC records are missing or wrong.
- Certificate issuance fails when a CAA record does not allow your certificate authority, or when the authority cannot find the validation record it asked you to publish.
- A site can load on one network and fail on another when resolvers hold different cached answers, or when DNSSEC validation fails on resolvers that check signatures.
The first check when a domain stops resolving
Look up the records yourself and compare what different resolvers return. If they agree with each other but not with what you expect, the records are wrong; if they disagree, a cache or DNSSEC is the likely cause.
DNS Lookup queries the public resolver you pick (Cloudflare, Google or Quad9) and runs the lookup again when you switch, so you can compare their answers.