What is a top-level domain (TLD) name server?

A top-level domain (TLD) name server is an authoritative DNS server for a TLD such as .com, .org, .uk or .dev. It sits one level below the root servers and one level above the name servers for individual domains. Its job is to know, for every domain registered under that TLD, which name servers are responsible for it. When a resolver asks a .com server about www.example.com, the TLD server doesn't return the website's IP address. It replies with a referral: the NS records for example.com, plus any glue addresses and DNSSEC DS records, so the resolver knows exactly where to ask next.

TLD servers are where domain registration and DNS meet. The name servers you set at your registrar end up on these servers, and mistakes there are behind many "my domain stopped working" problems. In this article you'll learn the different kinds of TLD, who runs their name servers, exactly what data they hold, how changes reach them, and how to query them directly to check your own domain's delegation.

Where TLD Name Servers Fit

A full DNS lookup for www.example.com moves down the tree one level at a time:

1. A root server tells the resolver which servers handle .com.
2. A .com TLD server tells the resolver which servers handle example.com.
3. An authoritative name server for example.com returns the A record for www.example.com.

The TLD server is the middle step. Resolvers cache its referrals, typically for up to two days for .com, so most lookups don't need to reach it at all. But whenever a resolver meets a domain it hasn't seen recently, it has to ask the TLD.

Types of Top-Level Domain

IANA groups TLDs into several categories. The name servers work the same way for all of them, but the rules for who can register and how the registry is run differ.

Type	Examples	Notes
Generic (gTLD)	.com, .net, .org, .info	Open to anyone, governed by contracts with ICANN
New gTLDs	.dev, .app, .shop, .xyz	Added from 2013 onwards under ICANN's New gTLD Program
Brand TLDs	.google, .bmw	Operated by a company for its own use
Sponsored (sTLD)	.gov, .edu, .museum	Restricted to a particular community
Country code (ccTLD)	.uk, .de, .jp, .io	Two letters, run under local policy rather than ICANN contracts
Internationalised (IDN)	.рф, .中国	Non-Latin scripts, stored in DNS as xn-- punycode labels
Infrastructure	.arpa	Used for technical purposes such as reverse DNS

In October 2026 the root zone delegates roughly 1,440 TLDs, and every one of them has its own set of TLD name servers.

Registries, Registrars and Registrants

Three roles are involved in every domain, and it's easy to mix them up:

• Registry: The organisation that runs a TLD. It maintains the authoritative database of every domain under that TLD and operates (or contracts out) the TLD name servers. Verisign runs .com and .net, Nominet runs .uk, DENIC runs .de, and Public Interest Registry runs .org.
• Registrar: The company you buy a domain from. It talks to the registry on your behalf, usually using a protocol called EPP (Extensible Provisioning Protocol).
• Registrant: You, the person or organisation that holds the domain.

When you change your domain's name servers in your registrar's control panel, the registrar sends that change to the registry over EPP. The registry updates its database and publishes the new NS records on its TLD name servers. That's the only way information gets onto a TLD server: you can't edit the TLD zone directly, and your DNS host can't either, unless it's also your registrar.

Many registries outsource the actual DNS operation to specialist providers. For example, the .org name servers have names under afilias-nst.info and afilias-nst.org, and .dev uses servers under charlestonroadregistry.com, which belongs to Google.

Finding the Name Servers for a TLD

Ask for the NS records of the TLD itself:

dig com NS +short

a.gtld-servers.net.
b.gtld-servers.net.
c.gtld-servers.net.
d.gtld-servers.net.
e.gtld-servers.net.
f.gtld-servers.net.
g.gtld-servers.net.
h.gtld-servers.net.
i.gtld-servers.net.
j.gtld-servers.net.
k.gtld-servers.net.
l.gtld-servers.net.
m.gtld-servers.net.

A few other examples:

dig uk NS +short
dig org NS +short
dig dev NS +short

dns1.nic.uk.
dns2.nic.uk.
dns3.nic.uk.
dns4.nic.uk.
a0.org.afilias-nst.info.
a2.org.afilias-nst.info.
b0.org.afilias-nst.org.
b2.org.afilias-nst.org.
ns-tld1.charlestonroadregistry.com.
ns-tld2.charlestonroadregistry.com.
ns-tld3.charlestonroadregistry.com.
ns-tld4.charlestonroadregistry.com.

(Output trimmed: some TLDs list more servers than shown here.) Like the root servers, most TLD name servers use anycast, so each name is served from many locations around the world.

IANA's Root Zone Database at https://www.iana.org/domains/root/db lists every TLD with its registry operator and name servers, which is useful when you need to know who runs an unfamiliar TLD.

What a TLD Name Server Stores

A TLD zone is huge in terms of the number of domains, but each domain only has a few records in it. For every delegated domain, the TLD server typically holds:

• NS records: The name servers you set at your registrar.
• Glue records (A and AAAA): The IP addresses of those name servers, but only when the name servers sit inside the domain they serve, such as ns1.example.com for example.com. Without glue, a resolver would have no way to find them.
• DS records: If you've enabled DNSSEC, a hash of your domain's key that links your zone to the TLD's chain of trust.

What it doesn't store is just as important:

• No A, AAAA, MX, TXT or CNAME records for your domain.
• No website or email settings of any kind.
• No records for your subdomains.

All of those live on your domain's authoritative name servers. That's why changing a website's IP address takes effect without contacting the registry, but changing which DNS provider you use always does.

The TLD zone also holds a few records for itself, such as its SOA, its own NS set and its DNSKEY records.

Querying a TLD Server Directly

Asking a TLD server directly shows you exactly what the registry is publishing, without any resolver caching in between. Always use +norecurse, because TLD servers don't offer recursion.

dig @a.gtld-servers.net example.com NS +norecurse

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3622
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1

;; QUESTION SECTION:
;example.com.                   IN      NS

;; AUTHORITY SECTION:
example.com.            172800  IN      NS      ns1.example.net.
example.com.            172800  IN      NS      ns2.example.net.

Points to notice:

• The records are in the authority section, not the answer section, and the aa flag is missing. That's what a referral looks like. The .com server isn't authoritative for example.com; it's just telling you who is.
• The TTL is 172,800 seconds (two days). This is the delegation TTL set by the registry, and it's why name server changes can take up to a couple of days to be seen everywhere.

Checking Glue

For a domain that uses in-domain name servers, the TLD includes glue in the additional section:

dig @a.gtld-servers.net example.com NS +norecurse

;; AUTHORITY SECTION:
example.com.            172800  IN      NS      ns1.example.com.
example.com.            172800  IN      NS      ns2.example.com.

;; ADDITIONAL SECTION:
ns1.example.com.        172800  IN      A       192.0.2.53
ns1.example.com.        172800  IN      AAAA    2001:db8::53
ns2.example.com.        172800  IN      A       198.51.100.53

If these addresses are wrong or missing, resolvers can't reach your name servers, and your whole domain stops resolving.

Checking DS Records

The DS record is the one record the TLD server is authoritative for on your behalf, so it does come back as an answer:

dig @a.gtld-servers.net example.com DS +norecurse +noall +answer

example.com.            86400   IN      DS      2371 13 2 C988EC423E3880EB8DD8A46FE06CA230EE23F35B578D64E78B29C3E1 C83D245A

If you're moving DNS providers or troubleshooting DNSSEC, this is the definitive check of what the registry is publishing.

Asking for a Domain That Doesn't Exist

dig @a.gtld-servers.net this-name-is-not-registered-12345.com A +norecurse

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51203
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; AUTHORITY SECTION:
com.                    900     IN      SOA     a.gtld-servers.net. nstld.verisign-grs.com. 1791607234 1800 900 604800 900

Here the .com server is authoritative, because it knows for certain that no such domain is delegated, so it sets the aa flag and returns NXDOMAIN along with the TLD's SOA record. The extra authority records are DNSSEC proofs of non-existence. Incidentally, the .com zone is updated continuously, and its SOA serial is a Unix timestamp rather than a date.

Comparing the Parent and the Child

Your domain's NS records exist in two places: in the TLD zone (the parent) and in your own zone on your DNS provider's servers (the child). They should match. When they don't, you can get inconsistent behaviour, because some resolvers trust the parent's list and others replace it with the child's once they've reached your servers.

This short shell script compares both:

#!/usr/bin/env bash
set -euo pipefail

domain="${1:?usage: $0 domain}"
tld="${domain##*.}"

tld_server=$(dig +short "$tld" NS | head -n 1)

echo "Parent ($tld_server):"
parent=$(dig +norecurse @"$tld_server" "$domain" NS \
  | awk '$4 == "NS" { print tolower($5) }' | sort -u)
echo "$parent"

first_ns=$(echo "$parent" | head -n 1)

echo "Child ($first_ns):"
child=$(dig +norecurse +short @"$first_ns" "$domain" NS \
  | tr 'A-Z' 'a-z' | sort -u)
echo "$child"

if [ "$parent" = "$child" ]; then
  echo "OK: parent and child NS sets match"
else
  echo "WARNING: parent and child NS sets differ"
fi

Save it as check-delegation.sh, make it executable, and run it:

chmod +x check-delegation.sh
./check-delegation.sh example.com

Parent (a.gtld-servers.net.):
ns1.example.net.
ns2.example.net.
Child (ns1.example.net.):
ns1.example.net.
ns2.example.net.
OK: parent and child NS sets match

The script only handles single-label TLDs such as .com or .dev. For domains under a second-level suffix like .co.uk, query the servers for co.uk instead.

Looking Up Registry Data With RDAP

The DNS data on a TLD server comes from the registry's database, and you can query that database directly using RDAP (Registration Data Access Protocol), the modern, JSON-based replacement for WHOIS. For .com, Verisign's RDAP service is:

curl -s https://rdap.verisign.com/com/v1/domain/example.com \
  | python3 -c 'import json,sys; d=json.load(sys.stdin); print([n["ldhName"] for n in d["nameservers"]]); print(d["status"])'

['NS1.EXAMPLE.NET', 'NS2.EXAMPLE.NET']
['client delete prohibited', 'client transfer prohibited', 'client update prohibited']

RDAP also shows the domain's status codes, such as client hold or server hold, which explain why a domain might have been removed from the TLD zone even though it's still registered. IANA publishes the RDAP base URL for every TLD at https://data.iana.org/rdap/dns.json.

When TLD Problems Affect Your Domain

You can't break a TLD's servers, but problems at the TLD level can still take your domain offline:

• Expired domains: When a domain expires, the registry often removes its delegation, so resolvers get NXDOMAIN from the TLD server.
• Hold statuses: A clientHold or serverHold status removes the domain from the zone, often because of unpaid fees or abuse complaints.
• Wrong name servers at the registrar: A typo in the name servers you set means the TLD sends resolvers to the wrong place.
• Stale glue: Changing your name server's IP address without updating the glue at the registrar leaves resolvers pointing at the old address.
• Mismatched DS records: A DS record that doesn't match your current DNSSEC keys causes validating resolvers to return SERVFAIL.

In every case, querying the TLD server directly, as shown above, is the fastest way to confirm what's being published.

---

FAQ: TLD Name Servers

---

Conclusion

A TLD name server is the middle step in every DNS lookup. It knows, for every domain under its TLD, which name servers to ask next, and it hands resolvers a referral with the NS records, any glue, and the DS record that links your DNSSEC keys to the chain of trust. Everything else about your domain lives on your own authoritative servers.

Because the only way to change what a TLD publishes is through your registrar, many delegation problems come down to a typo, an outdated glue record or a forgotten DS record. Querying the TLD directly with dig +norecurse and checking RDAP takes a minute and tells you exactly what the rest of the internet sees.