--- id: "root-zone" kind: "glossary-term" title: "root zone" language: "en" category: "DNS and technical foundations" updated: "2026-10-10T10:28:55Z" canonical: "https://tldlog.com/glossary/root-zone/" translations: es: "https://tldlog.com/es/glosario/zona-raiz/" de: "https://tldlog.com/de/glossar/root-zone/" fr: "https://tldlog.com/fr/glossaire/zone-racine/" it: "https://tldlog.com/it/glossario/zona-radice/" pt-BR: "https://tldlog.com/pt/glossario/zona-raiz/" ru: "https://tldlog.com/ru/glossariy/kornevaya-zona/" zh-Hans: "https://tldlog.com/zh/cihui/genqu/" --- # root zone The top level of the DNS. It lists every TLD, such as .com or .es, and the name servers for each one. Adding a new TLD to the internet means adding it to the root zone, a process coordinated through IANA. The root zone is the top of the Domain Name System: a small, public list of every top-level domain (TLD), such as .com or .es, and of the servers that answer for each one. When a resolver does not know where to find a TLD, it asks a root server, which answers from the root zone. A TLD only works on the internet once it is listed there. ## What the root zone is and what it contains IANA describes the root zone as "principally composed of delegations of top-level domains". For each TLD it holds the name servers, as NS records, and the DS records that link the TLD into the DNSSEC chain of trust. It also carries the addresses of the root servers themselves. It holds no individual domains such as example.com: it only points to each TLD's servers. Anyone can download the complete root zone file from IANA, with the same data the root servers serve. IANA also keeps the Root Zone Database, which records each TLD's manager, technical details and contacts. The root zone has been signed with DNSSEC since July 2010. ## Root servers: how many there are and who runs them The root zone is served by 13 named identities, a.root-servers.net to m.root-servers.net. That number counts names and addresses, not machines: IANA describes "a network of hundreds of servers in many countries". As of 9 October 2026, root-servers.org counted 2,047 operational instances run by 12 independent organizations; Verisign runs two identities, a and j. Under a 2019 RSSAC statement, operators must stay independent of each other and of any government or overarching organization, and they work under different legal jurisdictions. ## How a TLD is added to or removed from the root Adding a TLD is called delegation, a separate step from applying for it. For a new gTLD, it comes after ICANN signs a Registry Agreement and runs pre-delegation testing. The registry operator then submits its manager, contacts, name servers and DS records through IANA's Root Zone Management system, and its NS records are placed in the root zone. Every root zone change, including new name servers for an existing TLD, goes through IANA's reviews and technical tests and must be confirmed by the TLD's contacts before it is implemented. A substantial change of control is treated as a redelegation, with its own criteria. A ccTLD exists because its country or territory has a code in ISO 3166-1. When the code is removed, IANA issues a Notice of Removal. As of October 2026, the ccTLD goes after five years by default, or at most 10 if an extension is requested within 12 months of the notice. The ICANN Board adopted this policy on 22 September 2022. A gTLD whose Registry Agreement is terminated, and which ICANN does not move to a successor registry operator, has its delegation revoked; the string may be offered again in a future application round. ## Who controls changes: IANA, the maintainer and the operators - **IANA**, whose functions are performed by PTI, an ICANN affiliate, checks each change request and keeps the Root Zone Database. Changes start with the TLD manager, who submits them online and must confirm them. - **Verisign**, as Root Zone Maintainer under an agreement with ICANN, compiles the zone at IANA's direction, signs it with the zone signing key and sends it to the operators. As of October 2026, the agreement (signed on 28 September 2016, amended on 20 October 2024) runs for eight-year terms that renew automatically. - **The root server operators** serve the zone exactly as distributed. RSSAC001 (December 2015) notes that an operator could not alter the signed data without invalidating its signatures. ## Myths about "turning off the internet" at the root - **There is no single switch.** Twelve independent operators in different jurisdictions run more than 2,000 instances. - **Operators cannot quietly edit entries.** DNSSEC signatures would expose a change. - **A short outage barely shows.** According to RFC 8806, resolvers usually keep TLD data cached for "on the order of a day or two". That does not make the root immune. On 23 December 2025, a DDoS attack hit 10 of the 13 identities, peaked at over one terabit per second and lasted just under ten minutes. The operators' July 2026 report found no known errors visible to end users, only minor delays for some lookups, and credits the operators' independence and diversity. ## Local copies of the root and why resolvers keep them A resolver normally starts from root hints, a short list of root server names and addresses, usually built into its software; IANA publishes the official version. At start-up the resolver asks a root server for the current list, a step called priming (RFC 9609, February 2025), because root server addresses occasionally change. A hyperlocal root goes further: the resolver keeps a full copy of the root zone on the same machine and answers only itself (RFC 8806, June 2020). The copy must be DNSSEC-validated and identical to the real zone; if it cannot be refreshed in time, the resolver must switch back to the root servers at once. The stated goals are reliability during attacks and privacy. RFC 8806 expects little speed gain for existing TLDs, which are usually cached already, and warns that a faulty setup can give users bad data. A hyperlocal root copies the official zone; an alternative root changes it. As of 9 October 2026, the root KSK rollover is scheduled for 11 October 2026, when KSK-2024 takes over from KSK-2017. Validating resolvers, hyperlocal roots included, need the updated trust anchor. ## Sources - [Root Zone Management (IANA)](https://www.iana.org/domains/root) - [Root Zone Change Request Process (IANA)](https://www.iana.org/help/root-zone-process) - [December 2025 DDoS against multiple DNS root servers (root server operators)](https://root-servers.org/media/news/2025-12-23_DDoS.pdf) - [RFC 8806: Running a Root Server Local to a Resolver](https://www.rfc-editor.org/rfc/rfc8806.txt) ## related terms - [root server](https://tldlog.com/glossary/root-server/) - [delegation (TLD)](https://tldlog.com/glossary/delegation/) - [IANA](https://tldlog.com/glossary/iana/) - [PTI](https://tldlog.com/glossary/pti/)