How DNS works: from the dot at the root to the whois record

Every domain name ends with a dot you never type

The name you type is not the full name. example.com is shorthand; the real, fully qualified name is example.com. — with a trailing dot. That dot is the root, and it is the top of the entire naming system. Everything else hangs below it.

Read a domain right to left and you are reading the chain of authority:

• . — the root. One zone for the whole internet.
• com. — a top-level domain, delegated by the root.
• example.com. — a second-level domain, delegated by .com.
• www.example.com. — a name inside that domain, controlled entirely by whoever holds it.

Each level knows only one thing about the level below: which servers to ask next. The root does not know the address of example.com; it knows who runs .com. The .com servers do not know the address either; they know which nameservers were declared for example.com. Only those last servers hold the actual answer. This is the whole design, and everything below follows from it.

The root zone: thirteen names, hundreds of locations

The root zone is a small file. It lists every top-level domain and the nameservers delegated to run it — about 1,500 entries, a few megabytes of text. It is the single point from which all name resolution starts.

It is served by thirteen named servers, a.root-servers.net through m.root-servers.net. That number is often misread as "there are only thirteen machines holding the internet together". There are not. Thirteen is the count of names, and it was chosen because a DNS response had to fit in a 512-byte UDP packet — thirteen server records was what fitted.

Behind those thirteen names are twelve independent operating organisations — universities, government agencies, network operators, non-profits — running well over a thousand physical instances between them, spread across the world. They share addresses using anycast: the same IP address is announced from many locations at once, and the routing system delivers your query to the nearest one. Losing a whole continent's worth of instances degrades service; it does not stop it.

The content of the root zone is not decided by whoever runs the servers. Changes go through IANA — the function that maintains the registries of names, numbers and protocol parameters — and are published from there. The servers distribute; they do not decide.

Who runs a top-level domain, and who sells you a name

Three different parties are involved in every domain, and confusing them is behind most misunderstandings about who can fix what.

Registry

The organisation that operates one TLD: it holds the zone, runs the authoritative nameservers for it and decides the rules of that zone. There is exactly one per TLD.

Registrar

The company you buy a name from. It has a contract with the registry and talks to it over a protocol called EPP. Many registrars per registry; you can move between them.

Registrant

You. You hold the right to use the name for a period, and you set its nameservers.

So when a domain is suspended, the registrar or the registry did it — not your hosting company. When a website is down but the name still resolves, the registry is fine and the problem is elsewhere. The registry record tells you which registrar a name is held through and what state the registry considers it to be in.

The kinds of top-level domain

Generic (gTLD)

.com, .net, .org, .info, .biz and, since the expansion round that opened in 2012, well over a thousand more — .site, .online, .shop, .app and the rest. All operate under contract with ICANN, and that contract is why they share rules: standard status codes, mandatory RDAP, transfer procedures.

Country-code (ccTLD)

Two letters assigned from the ISO country list: .ua, .de, .pl. These are not under the gTLD contract. Each is run under its own national arrangement, with its own rules on who may register, what data is published and which protocols are offered. This is why ccTLDs behave so inconsistently compared with generic domains.

Country-codes used as brands

.io, .co, .me, .tv, .ai are technically country-code domains that are marketed worldwide. Technically they follow ccTLD rules, which occasionally surprises people who assumed the generic-domain protections applied.

Infrastructure

.arpa — not for websites. It holds in-addr.arpa and ip6.arpa, the zones that map addresses back to names. Reverse DNS is a normal delegation inside the same hierarchy, which is why the holder of an address block controls it and the holder of the website does not.

The twelve TLDs, and where their records come from

Taking a concrete set — the ones used most often in generated test data — here is what kind of zone each is and which lookup protocol answers for it:

The distinction in the last row matters. For a generic domain, RDAP is a contractual obligation: ICANN required it of every gTLD registry and registrar from August 2019. For a country-code domain there is no such contract — the operator publishes RDAP because it decided to. Most of the commercially marketed ones do; plenty of national ones do not.

Registry operators change hands. Registries are bought and sold, and the company running a TLD today may not be the one running it in three years. The authoritative, always-current answer to "who operates this TLD" is IANA's root zone database, not any article — including this one.

How a name is actually resolved

You type a name. What happens next involves at least four different machines, and understanding the split explains most DNS problems.

1. Your device asks its resolver. The stub resolver in your operating system does not walk the hierarchy itself. It sends one question to a recursive resolver — your provider's, or one you configured — and waits for a complete answer.
2. The resolver asks the root. If it knows nothing yet, it asks a root server for www.example.com. The root does not answer with an address. It answers with a referral: "ask the .com servers, here they are".
3. The resolver asks .com. Another referral: "the nameservers for example.com are these".
4. The resolver asks those. They are authoritative for the zone, and they answer with the actual record.

The resolver then caches every step and hands you the answer. The next person asking for anything under .com skips step 2; the next person asking for that exact name skips everything. In practice the root is asked rarely — which is precisely why thirteen names can serve the world.

Two consequences worth holding on to:

• You almost never see the authoritative answer directly. You see what your resolver cached. That is why a record you changed an hour ago still looks old, and why two people can honestly report different results at the same moment.
• "Propagation" is a misnomer. Nothing is pushed anywhere. Caches are simply holding an answer they were given permission to hold, for as long as its TTL said. Our DNS lookup shows what the authoritative servers say to our resolver right now, which is often the fastest way to tell "the record is wrong" apart from "the record is fine and your cache is old".

Delegation, glue, and the mismatch that breaks half a site

A delegation is just an NS record in the parent zone. .com contains, for example.com, a list of nameserver names — and nothing else about the domain.

That creates an obvious circularity when the nameservers live inside the domain they serve. If example.com is served by ns1.example.com, you cannot find ns1.example.com without first asking example.com. The fix is a glue record: the parent zone stores the nameserver's address alongside the delegation, breaking the loop. Glue is why the registrar asks for IP addresses when you use nameservers inside your own domain, and why forgetting to update it after a server move takes the whole domain offline in a way that looks inexplicable.

The other classic failure is a mismatch between the parent and the zone itself. The registry publishes one set of nameservers; the zone's own NS records list another — usually because an old provider was never removed. Resolvers pick between them, so the site works for some people and not others, and every attempt to reproduce the fault gives a different result. Compare the NS records in the zone with the ones in the registry record; if they differ, you have found it.

Thin and thick registries: why two lookups disagree

Some registries store the whole record about a domain; others store almost nothing.

Thin

.com and .net. The registry holds the registrar, the nameservers and the dates. Everything about the holder lives at the registrar. A registry lookup on a .com domain genuinely cannot tell you more, because more is not there.

Thick

Most newer generic domains and many country codes. The registry holds the complete record centrally.

This is why the same domain can produce two different answers depending on who you asked, and why both are correct: the registry is authoritative for the delegation and the dates, the registrar for everything about the customer.

whois: port 43, and the referral chain that makes it work

Whois is the original lookup protocol, written down in 1982. The mechanism is minimal: open a TCP connection to port 43, send a line of text, read whatever comes back as free-form text, connection closed. No schema, no field names, no agreement on layout. Every registry answers in its own format.

The obvious question is how a client knows which server to ask for a given zone, given there are around 1,500 of them. The answer is a two-step referral, and it is worth knowing because it is the same procedure the console whois command follows:

1. Ask whois.iana.org about the object. IANA does not hold registration data; it holds the registry of registries.
2. Its answer contains a line beginning refer: or whois: — the address of the server that actually has the record. Ask that one.

Two connections, no private list of "zone to server" mappings. That matters: any such list starts going out of date the moment it is written, and it does so silently — a stale entry does not produce an error, it produces an answer from the wrong server.

The reason whois survived forty years is that a human can read any registry's output. The reason it is being retired is that a program cannot — not reliably, not across registries, and not without breaking the next time somebody edits a template.

RDAP: the replacement, and how it finds the right server

RDAP — the Registration Data Access Protocol — answers the same questions over HTTPS, in JSON, with standardised field names. It was specified in 2015 and the query and response documents were revised in 2021. Beyond the format, it brought three things port 43 never had: internationalised data with a declared encoding, a machine-readable way to state that a field was deliberately withheld, and bootstrapping.

Bootstrapping is the RDAP answer to the same "which server do I ask" problem. IANA publishes machine-readable bootstrap files — one for domains, one for IP address blocks, one for AS numbers — that map each zone or range to the base URL of the responsible RDAP service. A client fetches those files, caches them, and from then on knows where to send any query. There are also public redirectors that implement the bootstrap for you: you send every query to one address and it forwards you to the right registry.

The timeline explains why tools disagree. ICANN made RDAP mandatory for generic-domain registries and registrars in August 2019, ran both protocols in parallel for years, and retired the contractual requirement to keep port 43 running at the start of 2025. Many operators still run it voluntarily; a growing number no longer do. Country-code domains are their own world — some publish RDAP, some publish only port 43, and a few publish neither and expect a web form.

In practice this means a client asks RDAP first and falls back to port 43 for exactly one reason: the bootstrap has no entry for that zone. A network error or a rate-limit response is not a reason — asking the same question of a second server after the first refused is the shortest path to being limited by both, and the second server usually belongs to the same registry anyway.

"There is no such name" is an answer, not a failure

DNS has a dedicated response for a name that does not exist — NXDOMAIN — and it is authoritative: the server responsible for the zone is stating that nothing by that name is there. It is a different result from "the name exists but has no record of the type you asked for", and different again from "I could not reach anyone who knows".

The protocol treats these differences seriously enough to cache them separately. Negative caching, specified in 1998, lets a resolver remember a "does not exist" answer, and the period is set by the zone itself in its SOA record — typically minutes to hours. Without it, every mistyped name and every automated probe for a name that was never created would travel all the way to the authoritative servers, every time.

This is also the reason a newly created record sometimes fails to appear for one particular person while working for everyone else: they asked too early, received a valid negative answer, and their resolver is holding it until it expires. Nothing is broken, and nothing they do will speed it up.

Registry lookups face the same problem one level up. Registries publish records for hundreds of millions of domains and are queried constantly, so essentially all of them rate-limit by source address, and RDAP services return an explicit "too many requests" status when a client goes over. A client that treats "no such domain" as a temporary error and retries is generating load that produces nothing — which is why the rate limits exist in the first place, and why any tool built on these protocols is expected to remember an answer rather than re-ask for it.

DNSSEC: the chain that follows the same hierarchy

Nothing in plain DNS proves that an answer came from the right server. DNSSEC adds signatures, and it validates along exactly the same delegation chain: the root signs its statement about .com's key, .com signs its statement about example.com's key, and example.com signs its records. A resolver that validates walks that chain from a key it already trusts — the root key — down to the answer.

The failure mode is worth knowing because it is dramatic and asymmetric. If a zone's signatures expire, every resolver that validates refuses to answer at all, while every resolver that does not validate keeps working normally. The domain is completely dead for some people and completely fine for others — which is why the reports never agree and why "it works for me" is uninformative here.

Putting it together

When something about a domain is wrong, the hierarchy tells you where to look, in order:

1. Does the registry still delegate it? Status codes in the registry record — a domain on hold is out of the DNS entirely, and nothing on your server will change that.
2. Do the parent's nameservers match the zone's? Registry NS versus zone NS. A mismatch produces intermittent, unreproducible failures.
3. Does the zone answer, and with what? A, AAAA, MX and TXT in one query — most real problems are a disagreement between record types, not a fault inside one.
4. Do the addresses lead anywhere? Who runs the address a name points at, and whether it is still infrastructure you control. A record still aimed at a hosting provider you left two years ago is common and quietly dangerous.
5. Does the server actually answer? What the web server returns — because by this point the name is not the problem.