ds

The root zone

Every domain name is answered by starting at the root, which knows one thing: which servers to ask about each top-level domain. That list is a file — about two megabytes of it — published by IANA and served by the thirteen root servers, and it is the only authority on what a TLD is. A name a registrar will happily sell you but the root does not carry cannot resolve. This page is that file, read at build time: serial 2026090900, on 2026-09-09.

Delegated
1,438TLDs in the root
Signed
1,35094% with a DS record
Name servers
5,9227,563 delegations
Glue
11,5825,646 of them IPv6
Covered by ds
1,357of 1,438 TLDs

The thirteen root servers

Thirteen names, twelve organisations, and — through anycast — well over a thousand physical machines answering on those addresses around the world. Thirteen because that was as many as would fit in a 512-byte DNS response when the number was fixed, and it has not needed to change since. Every resolver on the internet is born knowing these addresses; everything else it learns by asking.

ServerIPv4IPv6Run by
a.root-servers.net198.41.0.42001:503:ba3e::2:30was ns.internic.net
b.root-servers.net170.247.170.22801:1b8:10::bwas ns1.isi.edu
c.root-servers.net192.33.4.122001:500:2::cwas c.psi.net
d.root-servers.net199.7.91.132001:500:2d::dwas terp.umd.edu
e.root-servers.net192.203.230.102001:500:a8::ewas ns.nasa.gov
f.root-servers.net192.5.5.2412001:500:2f::fwas ns.isc.org
g.root-servers.net192.112.36.42001:500:12::d0dwas ns.nic.ddn.mil
h.root-servers.net198.97.190.532001:500:1::53was aos.arl.army.mil
i.root-servers.net192.36.148.172001:7fe::53was nic.nordu.net
j.root-servers.net192.58.128.302001:503:c27::2:30VERISIGN, INC.
k.root-servers.net193.0.14.1292001:7fd::1RIPE NCC
l.root-servers.net199.7.83.422001:500:9f::42ICANN
m.root-servers.net202.12.27.332001:dc3::35WIDE

From the root hints file, last updated September 08, 2026 against root zone serial 2026090803. Four of the thirteen name their operator in the file itself; the rest give only the hostname the server answered on before the .root-servers.net names existed, which is the only attribution the file carries.

DNSSEC

The root signs its own records and publishes a DS record — a fingerprint of the TLD's signing key — for each signed TLD. That is what lets a resolver follow one chain of signatures from a key it was configured with all the way down to an answer, and refuse anything that does not verify. 1,350 of the 1,438 delegated TLDs are signed (94%); the other 88 are not, and names under them are taken on trust.

Trust anchors

The keys IANA publishes for the root itself — the one thing a validating resolver has to be told rather than look up. Everything else in the DNS is verified by following signatures down from here.

  • key 20326RSA/SHA-256 · SHA-256 · from 2017-02-02 — in force, and in the zoneE06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
  • key 38696RSA/SHA-256 · SHA-256 · from 2024-07-18 — in force, and in the zone683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16
  • key 19036RSA/SHA-256 · SHA-256 · from 2010-07-15 until 2019-01-11 — retired49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5

The root's own key-signing keys are 20326 and 38696 and it signs the zone with zone-signing key 57780, all RSA/SHA-256. Key tags are computed from the keys in the zone by the build script, so an anchor that stopped matching the zone would show up here rather than being taken on faith.

What the TLDs sign with

One row per algorithm, counted over the 1,481 DS records in the root — a signed TLD often publishes two while it rolls a key.

  • RSA/SHA-2561,197
  • ECDSA P-256/SHA-256244
  • RSA/SHA-51229
  • RSASHA1-NSEC3-SHA17
  • Ed255193
  • ECDSA P-384/SHA-3841

RSA still signs most of the root, but the elliptic-curve algorithms — smaller keys, smaller answers — are where new TLDs go.

The 88 unsigned TLDs

No DS record in the root, so validation stops at the top: a resolver cannot tell a genuine answer under one of these from a forged one. Names under them resolve perfectly well — this is how all of the DNS worked before 2010 — but nothing about the answer is provable.

What the root carries, and what ds knows

The root zone is the list of TLDs that exist; the tables ds bundles are the list it can look something up in. They are not the same list, and the gaps in both directions are worth naming — the whole point of building this page from the zone is that it can contradict us.

Delegated, but not in ds

81 TLDs the root delegates that ds has no row for: no registry service in the bundled WHOIS table, none in IANA's RDAP bootstrap, and no registrar pricing them. Mostly country codes whose registry publishes nothing public — and a run of IDN ccTLDs. A name under one of these is a name ds cannot answer for at all.

  • .bv
  • .bw
  • .cf
  • .ck
  • .cu
  • .er
  • .fk
  • .ga
  • .gb
  • .gq
  • .gu
  • .hm
  • .il
  • .jm
  • .kh
  • .km
  • .kp
  • .kw
  • .lr
  • .mh
  • .mm
  • .np
  • .pf
  • .py
  • .sj
  • .sz
  • .va
  • .ve
  • .xn--2scrj9c
  • .xn--3hcrj9c
  • .xn--45br5cyl
  • .xn--45brj9c
  • .xn--4dbrk0ce
  • .xn--90a3ac
  • .xn--90ae
  • .xn--90ais
  • .xn--e1a4c
  • .xn--fpcrj9c3d
  • .xn--fzc2c9e2c
  • .xn--gecrj9c
  • .xn--h2breg3eve
  • .xn--h2brj9c
  • .xn--h2brj9c8c
  • .xn--j1amh
  • .xn--j6w193g
  • .xn--kprw13d
  • .xn--l1acc
  • .xn--lgbbat1ad8j
  • .xn--mgb9awbf
  • .xn--mgba3a4f16a
  • .xn--mgbaam7a8h
  • .xn--mgbah1a3hjkrd
  • .xn--mgbai9azgqp6j
  • .xn--mgbayh7gpa
  • .xn--mgbbh1a
  • .xn--mgbbh1a71e
  • .xn--mgbc0a9azcg
  • .xn--mgbcpq6gpa1a
  • .xn--mgberp4a5d4ar
  • .xn--mgbgu82a
  • .xn--mgbpl2fh
  • .xn--mgbtx2b
  • .xn--mgbx4cd0ab
  • .xn--mix891f
  • .xn--node
  • .xn--ogbpf8fl
  • .xn--p1ai
  • .xn--pgbs0dh
  • .xn--q7ce6a
  • .xn--qxa6a
  • .xn--qxam
  • .xn--rvc1e0am3e
  • .xn--s9brj9c
  • .xn--wgbh1c
  • .xn--wgbl6a
  • .xn--xkc2al3hye2a
  • .xn--xkc2dl3a5ee0h
  • .xn--y9a3aq
  • .xn--ygbi2ammx
  • .za
  • .zw

In ds, but not delegated

2 rows the root has never heard of. These reach the table through a registrar's price feed — some sell alternative-root and blockchain names alongside real TLDs — and they are worth showing rather than quietly dropping: whatever you can buy there, nothing under them resolves in the DNS.

Signed, of the ones ds carries

1,730 of the 1,806 rows that the root delegates are signed — counted per row, so .co.uk counts .uk's DS record, which is the one that actually secures it.

Where this comes from

Four files, fetched from IANA every time the site is built and parsed into the numbers above — so what you are reading is the root as it stood when this page was last deployed, not a copy of it kept in the repository going stale. Nothing here is our reading of anything: it is the zone, printed.

  • root.zone — the zone itself, and everything on this page about individual TLDs: their name servers, the glue addresses, the DS records.
  • named.root — the root hints: the thirteen servers and their addresses, which is what a resolver starts life knowing.
  • root-anchors.xml — the trust anchors, the keys DNSSEC validation begins from.
  • tlds-alpha-by-domain.txt — IANA's plain list of delegated TLDs, at version 2026090900, 1,438 entries. Used here as a second opinion on the zone's own count.

All four are linked from IANA's root files page. Per-TLD registry details — who runs a zone, where its registry is, what it costs — come from elsewhere and are on the TLD table and each TLD's own page.

Read on 2026-09-09.