TLD Servers

When root servers answer a query for www.example.com, they don't provide the final answer. Instead, they return a referral: "For anything ending in .com, ask these servers." The servers they point to are TLD (Top-Level Domain) servers—the second tier in the DNS hierarchy that organizes hundreds of millions of domain names into manageable namespaces.

TLDs are the rightmost segment of domain names: .com, .org, .net, .uk, .de, .io, .app, .museum. Each represents a distinct namespace managed by a specific registry. Understanding TLD servers means understanding how the Internet's address space is partitioned, governed, and operated.

Not all TLDs are created equal. They differ in purpose, governance, registration policies, and operational characteristics. The DNS categorizes TLDs into several types:

1. Generic TLDs (gTLDs)

These are TLDs available to any registrant worldwide, without geographic restriction. The original gTLDs were:

• .com (commercial)
• .org (organizations)
• .net (networks)
• .edu (educational institutions)
• .gov (US government)
• .mil (US military)
• .int (international organizations)

While .edu, .gov, .mil, and .int have registration restrictions, .com, .org, and .net are open to anyone. Today, .com alone contains over 160 million registrations—more than half of all domain names.

2. Country Code TLDs (ccTLDs)

These two-letter TLDs represent countries and territories, based on ISO 3166-1 alpha-2 codes:

• .uk (United Kingdom)
• .de (Germany)
• .jp (Japan)
• .cn (China)
• .br (Brazil)
• .in (India)
• .au (Australia)
• .ca (Canada)

There are over 250 ccTLDs, each governed by policies set by the respective country or territory. Some ccTLDs restrict registration to local entities (e.g., .au requires Australian presence); others operate openly (e.g., .io, originally for British Indian Ocean Territory, is popular with tech companies).

3. Sponsored TLDs (sTLDs)

These are specialized gTLDs with a sponsoring organization that establishes and enforces registration policies:

• .aero (air transport industry)
• .coop (cooperatives)
• .museum (museums)
• .travel (travel industry)
• .jobs (employment sites)

sTLDs serve specific communities with eligibility requirements.

For the first two decades of the commercial Internet, only a handful of gTLDs existed. Getting a meaningful .com domain became increasingly difficult as millions of obvious names were taken. In 2012, ICANN launched the New gTLD Program—the largest expansion of the DNS namespace in history.

The application process:

• Application window: January-April 2012
• Application fee: $185,000 per TLD
• Applications received: 1,930
• Unique TLD strings applied for: ~1,400

Applicants included brand owners seeking .google, .amazon, .apple; generic term seekers wanting .shop, .blog, .hotel; cities wanting .tokyo, .london, .nyc; and community groups seeking .church, .law, .bank.

Impact on the DNS infrastructure:

The gTLD expansion increased root zone size from ~300 entries to over 1,500 TLDs. This had several effects:

1. Root zone growth: The root zone file size increased several-fold, though it remains manageable (under 2 MB)

2. More TLD servers: Each new TLD requires its own authoritative infrastructure—registry operators must maintain highly available nameserver networks

3. Registry consolidation: Several operators run multiple TLDs. Donuts Inc., for instance, operates 200+ TLDs. Verisign operates .com, .net, and several new gTLDs

4. DNSSEC proliferation: New gTLDs were required to implement DNSSEC from launch, accelerating secure DNS adoption

Market realities:

Despite the availability of new gTLDs, .com remains dominant. Most new gTLDs have modest registration numbers (tens of thousands to low millions), while .com maintains 160+ million. Brand recognition and user expectation continue to favor .com, though .app, .io, and .dev have found niches in the tech industry.

TLD servers are authoritative nameservers for their respective zones. They maintain and serve data about all second-level domains registered within the TLD.

What TLD zone files contain:

The .com zone file, for example, contains NS records and glue for every registered .com domain:

; Excerpt from the .com zone
example.com.             172800  IN  NS  ns1.example.com.
example.com.             172800  IN  NS  ns2.example.com.
ns1.example.com.         172800  IN  A   203.0.113.10
ns2.example.com.         172800  IN  A   203.0.113.11

stackoverflow.com.       172800  IN  NS  ns-1029.awsdns-00.org.
stackoverflow.com.       172800  IN  NS  ns-1627.awsdns-11.co.uk.
; ... (160+ million more entries)

Zone file size comparison:

Managing a zone with 160 million entries presents significant challenges:

1. Memory requirements: TLD servers must keep the entire zone in memory for fast queries. This requires servers with substantial RAM.

2. Zone transfer overhead: When the zone file updates, secondary servers must receive the changes. For massive zones, incremental transfers (IXFR) are essential.

3. Update velocity: .com processes millions of registration changes daily. The zone generation and distribution system must handle continuous updates.

TLD server response example:

When a resolver queries a .com TLD server for www.example.com, the response looks like:

Key observations:

1. TLD servers return referrals: Like root servers, TLD servers don't have the final answer—they refer to the domain's authoritative servers

2. NS records for second-level domains: The TLD knows which nameservers are authoritative for each registered domain

3. Glue records when needed: If the authoritative servers are within the same TLD (e.g., ns1.example.com for example.com), glue records are included

4. No A/AAAA for the queried name: The TLD server doesn't store www.example.com's IP—that's the authoritative server's job

Understanding TLD servers requires understanding who operates them and how domain registration works. The DNS industry uses a registry-registrar model that separates wholesale and retail functions.

Registry: The Wholesale Operator

A registry is the organization that operates a TLD. It maintains the authoritative database of all domain registrations within that TLD and operates the TLD's nameservers.

Registry responsibilities include:

• Operating TLD authoritative nameservers (24/7, globally distributed)
• Maintaining the registration database (the source of truth)
• Generating zone files from registration data
• Operating the WHOIS/RDAP service for that TLD
• Enforcing TLD-specific policies
• Implementing DNSSEC for the TLD
• Processing registrar requests via EPP (Extensible Provisioning Protocol)

Registrar: The Retail Interface

Registrars are accredited companies that sell domain registrations to end users. They're the customer-facing layer:

• GoDaddy
• Namecheap
• Google Domains (now Squarespace Domains)
• Cloudflare Registrar
• Hover
• Gandi

Registrars connect to registries via EPP (Extensible Provisioning Protocol), an XML-based protocol for registration operations. When you register mybusiness.com through GoDaddy:

1. GoDaddy checks availability with Verisign (the .com registry)
2. You pay GoDaddy (retail price)
3. GoDaddy sends an EPP create command to Verisign
4. Verisign adds your domain to the .com zone
5. GoDaddy pays Verisign (wholesale price, ~$10 for .com)
6. Zone updates propagate to all .com TLD servers

TLD servers, like root servers, employ Anycast to achieve global availability and performance. However, TLD infrastructure varies significantly by operator resources and TLD size.

Verisign's .com/.net infrastructure (example of large-scale TLD):

Verisign operates one of the most sophisticated DNS infrastructures in the world:

• Global Anycast sites: 100+ locations worldwide
• Peak capacity: Designed to handle 10+ trillion queries per day (far exceeding normal load)
• Nameserver identities: 13 for .com (a.gtld-servers.net through m.gtld-servers.net)
• Uptime record: 100% availability maintained for 25+ years
• DDoS mitigation: Routinely absorbs attacks exceeding 1 Tbps

Backend registry operators:

Many TLDs—especially new gTLDs and smaller ccTLDs—don't operate their own infrastructure. Instead, they contract with backend registry operators:

• Identity Digital (Afilias): Operates backend for .org, .info, .pro, 100+ other TLDs
• CentralNic: Backend for .xyz, .online, various ccTLDs
• Nominet: Operates .uk and provides backend for other territories
• Google Registry: Operates .google, .dev, .app, .page and provides backend services

This consolidation creates efficiency but also concentration risk. An outage at a major backend operator affects multiple TLDs simultaneously.

TTL considerations:

TLD NS records in the root zone typically have TTL values of 172800 seconds (48 hours). This means resolvers cache TLD server information for two days, reducing query load on root servers. However, if a TLD's nameserver addresses change, propagation takes up to 48 hours—a significant consideration for infrastructure migrations.

Country code TLDs exhibit far more variation than gTLDs. Each is a product of its country's policies, technical culture, and registry decisions. Understanding these variations illustrates the diversity within the TLD landscape.

Registration restriction policies:

Namespace structure variations:

ccTLDs structure their namespaces differently:

Direct second-level registration (e.g., .de, .ca, .jp):

• example.de, example.ca, example.jp
• Registrants register directly under the ccTLD

Third-level registration under categories (e.g., .uk, .au, .br):

• example.co.uk (commercial)
• example.org.uk (organizations)
• example.com.au (commercial)
• example.gov.br (government)

Some ccTLDs have migrated between models. The UK now allows direct .uk registrations alongside traditional .co.uk, creating namespace complexity.

IDN ccTLDs:

Internationalized ccTLDs allow non-ASCII scripts:

These coexist with ASCII equivalents (e.g., .cn and .中国 both represent China).

TLD security is critical because TLD servers are the second link in the resolution chain. Compromising a TLD means potentially hijacking millions of domains.

DNSSEC at the TLD level:

DNSSEC (DNS Security Extensions) provides cryptographic authentication for DNS responses. At the TLD level, this means:

1. TLD zone signing: The registry signs every record in the TLD zone with its Zone Signing Key (ZSK)

2. DS records in root: The TLD's Key Signing Key (KSK) hash is published as a DS record in the root zone, creating a chain of trust from root to TLD

3. DS records for second-level domains: When domain owners enable DNSSEC, the TLD publishes DS records pointing to the domain's keys

DNSSEC adoption by TLD:

TLD-specific security measures: