# The Original Root Servers

Canonical: https://learndns.org/learn/1-3-root-servers/

> How the DNS root got from one server at USC-ISI to 13 anycast identities, who operates them, and why the letter count stuck.

At the very top of the DNS hierarchy sits the root zone — the starting point for every DNS query. The servers that host this zone are called **root servers**, and they're arguably the most critical infrastructure on the internet. Understanding how they came to be and how they operate reveals the delicate balance of technical necessity and geopolitical complexity that shapes internet governance.

## The Root of Everything

When your computer needs to look up `www.example.com`, the journey starts at the root. Here's the simplified process:

1. Your resolver contacts a root server: "Who handles `.com`?"
2. Root server responds: "Try these nameservers for `.com`"
3. Your resolver contacts the `.com` server: "Who handles `example.com`?"
4. And so on down the hierarchy

The root servers don't know about every domain — they only know who's responsible for each top-level domain (TLD). But this makes them the foundation. Without root servers, DNS cannot function.

## The Original Deployment

When DNS was first tested in 1984, there was one root server, and it was not at SRI-NIC. Jon Postel and Paul Mockapetris brought it up at the Information Sciences Institute (USC-ISI), on a PDP-10 running the early JEEVES software. SRI-NIC, which had published HOSTS.TXT, hosted a root server soon after. The [RSSAC history of the root server system](https://itp.cdn.icann.org/en/files/root-server-system-advisory-committee-rssac-publications/rssac-023-17jun20-en.pdf) records that sequence.

A single root server was a single point of failure. RFC 882 already said a zone should have more than one nameserver, and the root was no exception. Through 1985–1987 more servers were added, including a second at ISI and others chosen to serve NSFNET.

The A–M letters were not the 1984 design. The set of 13 named identities settled later. Several organizations in the operator table below — ICANN, Cogent, the Internet Systems Consortium — did not exist when the first server was turned on. Treating today's letter chart as the 1985 deployment mixes three decades together.

## Why Thirteen Letters?

A common question: why exactly 13 root servers (A through M)?

The answer is practical: DNS responses originally had to fit in a 512-byte UDP packet. With name compression, you could fit about 13 root server records in that space. Thirteen was the maximum, so thirteen it was.

Today, with EDNS allowing larger packets, we could theoretically have more root letters. But changing such fundamental infrastructure is politically and operationally difficult, so thirteen letters remain.

## The Root Server Operators

As of today, twelve organizations operate the thirteen root server letters:

| Letter | Operator | Headquarters |
|--------|----------|--------------|
| A | Verisign | USA |
| B | USC-ISI | USA |
| C | Cogent Communications | USA |
| D | University of Maryland | USA |
| E | NASA | USA |
| F | Internet Systems Consortium (ISC) | USA |
| G | U.S. DOD NIC (DISA) | USA |
| H | U.S. Army Research Lab | USA |
| I | Netnod | Sweden |
| J | Verisign | USA |
| K | RIPE NCC | Netherlands |
| L | ICANN | USA |
| M | WIDE Project | Japan |

Notice the geographic concentration — 10 of 13 letters are operated from the United States. This reflects DNS's ARPANET origins but has been a source of international tension.

## Anycast: Thirteen Letters, Thousands of Servers

Here's the key insight: thirteen root server "letters" doesn't mean thirteen physical servers.

**Anycast** allows multiple physical servers to share the same IP address. When you query the A root server (IP: 198.41.0.4), your packets automatically route to the nearest instance of that server.

Today's root server deployment:

| Letter | Number of Instances | Global Locations |
|--------|--------------------:|------------------|
| A | 12+ | Global |
| B | 6+ | Global |
| C | 8+ | Global |
| ... | ... | ... |
| J | 200+ | Global |
| K | 100+ | Global |
| ... | ... | ... |
| **Total** | **1,500+** | **Worldwide** |

What looks like 13 servers is actually over 1,500 instances distributed globally. This provides redundancy, reduces latency, and prevents any single location from being a bottleneck.

## What the Root Zone Contains

The root zone itself is surprisingly small — about 2 MB. It contains:

### NS Records for TLDs

```
com.      172800  IN  NS  a.gtld-servers.net.
com.      172800  IN  NS  b.gtld-servers.net.
...
org.      172800  IN  NS  a0.org.afilias-nst.info.
...
uk.       172800  IN  NS  ns1.nic.uk.
```

These records tell resolvers where to find the authoritative servers for each TLD.

### DS Records for DNSSEC

```
com.      86400   IN  DS  30909 8 2 ...
```

DS (Delegation Signer) records establish the chain of trust for DNSSEC validation.

### Glue Records

```
a.gtld-servers.net.  172800  IN  A  192.5.6.30
```

These A/AAAA records provide addresses for nameservers whose names are *within* the TLDs they serve.

The entire zone is publicly available and updates about twice daily.

## Root Zone Management

Who controls what goes in the root zone? This question has geopolitical implications.

### IANA Function

The Internet Assigned Numbers Authority (IANA) — now operated by ICANN — maintains the root zone database. They process requests to add, modify, or remove TLDs.

### Verisign's Role

Verisign, under a complex arrangement with ICANN and the US government, performs the technical operation of publishing and distributing root zone updates.

### US Government Oversight (Historical)

Until 2016, the US Department of Commerce (via NTIA) had authority over root zone changes. This meant, theoretically, the US government could veto TLD additions.

In October 2016, this oversight ended as the IANA functions were transitioned to ICANN's control.

### The Root Server System Advisory Committee

The operators coordinate through RSSAC (Root Server System Advisory Committee), part of ICANN's structure. RSSAC provides advice on root server operations and policy.

## Resilience and Attacks

Root servers are constantly under attack — they're obvious targets for anyone wanting to disrupt the internet.

### DDoS Attacks

Major DDoS attacks have targeted root servers:
- **October 2002**: A coordinated attack affected 9 of 13 root servers
- **February 2007**: Another major attack, though anycast deployment limited impact
- **November 2015**: Multiple attacks over several days

### Why They Survive

Root servers survive through:
- **Anycast distribution** (attack one location, others keep working)
- **Massive overcapacity** (normal load is tiny compared to capacity)
- **Caching** (most queries never reach root servers)
- **Filtering and scrubbing** (traffic cleaning by operators)

In practice, root server attacks have never caused widespread DNS failures. Caching means even if root servers were completely offline for hours, most DNS would keep working with cached data.

## The Root Zone KSK Ceremony

With DNSSEC, the root zone has a "Key Signing Key" (KSK) that authenticates the entire DNS trust chain. Changing this key requires an elaborate ceremony:

- Held at secure facilities in Virginia or California
- Multiple "Trusted Community Representatives" attend
- Hardware Security Modules store key material
- Every step is recorded and audited
- Livestreamed for transparency

These ceremonies happen several times per year and represent the most critical cryptographic operations in internet infrastructure.

## Key Takeaways

- **Root servers** sit atop the DNS hierarchy, directing resolvers to TLD nameservers
- Originally single instances, now **1,500+ instances** worldwide via anycast
- **Thirteen letters** (A-M) reflect early UDP size limits, not current infrastructure
- **Ten of thirteen operators** are US-based, reflecting ARPANET origins
- The root zone itself is **small (~2 MB)** and updates twice daily
- Root servers survive constant attacks through **anycast, caching, and overcapacity**
- **IANA/ICANN** manages root zone content; Verisign handles technical distribution

## Next

With root servers in place, the next question was: what top-level domains should exist? The answer came in 1985 with the creation of the original TLDs — .com, .net, .org, .edu, .gov, and .mil.