The DNS root system is the starting point for resolution in the global DNS. It is not one central server and it does not contain every domain’s final records. It publishes the root zone and refers resolvers toward top-level-domain authoritative services.
Root label and root zone
The DNS namespace has a zero-length root label, commonly written as a trailing
dot. The fully qualified form of www.example.com is therefore:
www.example.com.The root zone is the zone at that apex. It contains delegation data for
top-level domains such as com, country-code top-level domains, and the
infrastructure needed to serve those delegations.
Current DNS terminology distinguishes the root label, root zone, and root servers [4].
Thirteen named authorities, not thirteen machines
The root zone lists 13 named authorities:
a.root-servers.net.
...
m.root-servers.net.IANA describes these as 13 named authorities backed by a network of many server instances in many countries [1].
The lettered names are stable service identifiers. They should not be counted as physical machines, sites, or network paths.
Independent operators
The named authorities are operated by independent organizations. This operational diversity avoids placing the root service under one network, technology stack, or failure domain.
The Root Server Technical Operations Association publishes operator and instance information and explains the shared service model [3].
The operators serve the same coordinated root-zone content, but each manages its own infrastructure and deployment choices.
Anycast distributes an identifier
Most root service addresses are announced from multiple locations using anycast. Routing steers a packet toward an available instance for the destination address according to network conditions and policy.
Consequences:
- one root-server IP address can reach different physical instances from different networks;
- the nearest instance by geography is not necessarily the selected route;
- an instance or route can change without changing the root-server identifier; and
- a measurement from one network does not describe every root-service path.
Anycast expands resilience and reach; it does not turn the 13 identifiers into a larger number of DNS names.
Root hints bootstrap recursive resolution
A recursive resolver needs an initial list of root-server names and addresses. That bootstrap data is commonly called the root hints file. IANA publishes the root hints and root-zone files [2].
Hints are starting addresses, not a permanent claim that one exact instance will answer. After contact, DNS responses provide current root-server information that the resolver can cache and use.
Resolver software or operating packages normally maintain this data. An application user does not need to choose a lettered root server for ordinary lookups.
What a root server returns
For a typical query below a top-level domain, a root server returns a referral toward that top-level domain’s authoritative servers. It can also return authoritative data for names that belong to the root zone itself.
It does not:
- recurse through lower zones for the client;
- host every registered domain’s zone;
- return a website from DNS;
- control the registrant’s domain account; or
- guarantee that a delegated child zone works.
The next servers in the chain are responsible for progressively lower zone data.
Root zone management and root service are distinct
It helps to separate:
- root-zone management and publication, which coordinates the root-zone data;
- root-server operation, which serves that data through the 13 named authorities; and
- recursive resolution, which uses the root service when cached data does not already provide the next delegation.
These functions cooperate, but they are not one provider or machine.
What to record in a root observation
For a meaningful measurement, capture:
- queried root-server identifier and destination address;
- query name and record type;
- observation time and network viewpoint;
- response code, flags, referral, and TTLs; and
- whether the result came from a recursive resolver or direct authoritative query.
This keeps an observation scoped to the service instance and route actually reached.
Continue the learning path
Return to the complete root-to-answer lookup path or review zones, delegation, and glue before changing authoritative nameservers.