A TLD name server is an authoritative DNS server for a top-level domain such as .com or .uk. It does not hold the records for any website. Instead it holds the delegation for every domain in that TLD — the NS records (and glue where needed) that point each domain to its own authoritative name servers. TLD servers are run by the registry for that extension (Verisign for .com, Nominet for .uk, and so on).
When you type example.com into a browser, your computer does not magically know the website’s IP address. A recursive resolver has to walk the DNS hierarchy from the top, asking one tier at a time. TLD name servers are the crucial middle rung on that ladder: they sit between the root and the individual domains, directing traffic to the right place without ever serving a single web page themselves.
What happens when a domain is looked up?
A full lookup for example.com follows three referrals, each one narrower than the last. The resolver does the walking; each server only answers for its own level.
| Tier | Example server | What it knows | What it answers |
|---|---|---|---|
| Root name servers | a.root-servers.net … m.root-servers.net | Where every TLD’s servers are | “Ask the .com servers” (a referral) |
| TLD name servers | The .com servers (Verisign) | The delegation for every .com domain | “Ask example.com’s name servers” (NS + glue) |
| Authoritative servers | The domain’s host (e.g. Cloudflare, Route 53) | The actual records for example.com | The real A/AAAA/MX answer |
There are 13 logical root server identities, a through m at root-servers.net, operated by 12 organizations and served from thousands of anycast instances around the world. They are queried first, but only to learn which TLD servers to ask next. From there, the TLD name servers hand back the delegation, and the resolution finishes at the domain’s own authoritative servers.
An authoritative DNS server for a whole top-level domain. It stores the NS delegation (and glue) for every registered domain in that TLD, but never the websites’ own A, AAAA or MX records.
What do TLD name servers actually store?
This is the single most misunderstood point. A TLD name server is essentially a giant directory of signposts, not a database of websites. For each domain registered under it, the TLD zone contains:
- NS records — the hostnames of the domain’s authoritative name servers (for example,
ns1.cloudflare.comandns2.cloudflare.com). This is the delegation. - Glue records —
A/AAAArecords giving the IP of any name server whose hostname lives inside the domain being delegated (see below). - DS records — the DNSSEC hashes that let a resolver verify the child zone’s signing keys. The whole TLD zone is itself signed by the registry.
Notice what is missing: there is no record telling anyone where the example.com website is hosted. That answer lives one tier lower, on the domain’s authoritative servers, which is exactly why the TLD server has to refer the resolver onward rather than answer directly.
Delegation, in one sentence
Delegation is the act of a parent zone (the TLD) publishing NS records that hand authority for a name down to a child zone (your domain). The root delegates TLDs; the TLD delegates each registered domain. Every layer trusts the layer above it, all the way up to the IANA-maintained root zone.
Why are glue records necessary?
Glue records exist to break a logical loop. Suppose example.com uses name servers named ns1.example.com and ns2.example.com — that is, the name servers live inside the very domain they are supposed to serve. A resolver is told “to find example.com, ask ns1.example.com.” But to find the IP of ns1.example.com, it would first need to… resolve example.com. That is a deadlock.
The fix is a glue record: the TLD zone publishes the IP address of ns1.example.com directly, alongside the NS delegation. Now the resolver gets both the name server’s hostname and its address in the same referral, and the chicken-and-egg loop never forms. If a domain’s name servers live in a different domain (such as ns1.cloudflare.com), no glue is needed, because that other domain can be resolved independently.
How your name servers reach the TLD zone
You never edit the TLD zone yourself. You set your name servers at your registrar; the registrar relays them to the registry; the registry publishes them (with glue if needed) in the TLD zone. That published delegation is what makes a freshly registered domain reachable on the public internet.
Who runs the TLD name servers?
There is no single operator. Each TLD is run by its own registry, and that registry (or a DNS backend it contracts) operates the TLD name servers and publishes the zone:
| TLD | Type | Responsible organization |
|---|---|---|
.com | Generic | Verisign |
.org | Generic | Public Interest Registry (with its DNS backend) |
.uk | Country-code | Nominet |
Because these servers are queried constantly, the answers are cached by TTL all over the internet. A recursive resolver that has recently looked up any .com domain already knows the .com servers and will not bother the root again until its cached referral expires. That caching, combined with anycast, is what lets a tiny number of logical servers absorb trillions of queries a day. To decide which body has authority to create a TLD in the first place, see who controls TLDs and the role of ICANN.
★ Key takeaways
- A TLD name server holds the delegation for every domain in its TLD —
NSrecords and glue — not the websites’ own records. - Resolution walks three tiers: root → TLD → the domain’s authoritative servers.
- Glue records supply a name server’s IP in the parent zone to break the
ns1.example.com-inside-example.comdeadlock. - TLD servers are run by each registry (Verisign for
.com, Nominet for.uk); caching and TTLs mean they are not hit on every lookup.
Frequently asked questions
What is a TLD name server?
A TLD name server is an authoritative DNS server for a top-level domain such as .com or .uk. It holds the delegation records for every domain registered in that TLD and answers lookups with the NS records (and glue) that point to each domain’s own authoritative name servers. It does not store the websites’ A, AAAA or MX records itself.
What is the difference between a root server and a TLD server?
A root name server sits at the very top of DNS and answers a query by referring the resolver to the correct TLD’s name servers. The TLD name server is one step down: it refers the resolver to the authoritative name servers of the specific domain. Root servers know where the TLDs live; TLD servers know where each domain inside that TLD lives.
Who runs the TLD name servers?
Each TLD is operated by a registry, and that registry (or its DNS backend) runs the TLD name servers. For example, Verisign operates the .com servers, Public Interest Registry is responsible for .org, and Nominet runs .uk. IANA’s Root Zone Database lists the organization responsible for each TLD.
What are glue records and why are they needed?
Glue records are A/AAAA records published in the parent (TLD) zone that give the IP address of a name server whose hostname lives inside the same domain it serves. They solve a chicken-and-egg problem: if example.com is served by ns1.example.com, a resolver cannot find ns1.example.com without first resolving example.com. The glue record breaks that loop by supplying the IP directly.
Are root and TLD servers queried on every lookup?
No. Every answer in DNS carries a time-to-live (TTL), and recursive resolvers cache referrals from the root and TLD servers. Because the root zone and most TLD delegations change rarely and carry long TTLs, a resolver usually has them cached and only revisits the root or a TLD server when its cached copy expires.
How do my name servers end up in the TLD zone?
When you register a domain, you set its name servers at your registrar. The registrar passes that information to the registry, which publishes it as NS records (with glue if the name server is inside the same domain) in the TLD zone. Publishing that delegation is what makes your domain resolvable on the public internet.