Root hints and named.root

Introduction

Every recursive DNS resolver needs to know how to reach the root servers before it can resolve any domain name. This initial knowledge comes from a file known as the root hints file — a small, static list of root server hostnames and their IP addresses.

Root hints are a bootstrap mechanism. They exist to solve a chicken-and-egg problem: a resolver needs DNS to find servers, but it needs servers to do DNS. The hints file breaks this cycle by providing a hardcoded starting point.

The named.root file

The canonical root hints file is published by IANA and is commonly called named.root (reflecting its historical use with the BIND name server). It is also sometimes called db.root, named.cache, or root.hints depending on the resolver software.

The file is available at:

• https://www.internic.net/domain/named.root — The traditional distribution point, maintained by IANA.
• It can also be retrieved via DNS itself: dig . NS from a working resolver returns the same information.

The file uses standard DNS zone file format. Each entry is a resource record with the owner name, TTL, class, record type, and record data. The file includes a header comment with the last modification date and a serial number derived from the root zone.

How resolvers use root hints

Root hints play a specific role in the resolver lifecycle:

• Bootstrap — When a resolver starts with no cached data, it loads root server addresses from the hints file. These addresses are used to send the first queries to the root.
• Priming query — The resolver immediately sends a priming query (. IN NS) to one of the hint addresses. This query asks the root server for its own current NS records and addresses.
• Operational root set — The response to the priming query replaces the static hints in the resolver's cache. From this point forward, the resolver uses the primed data — the authoritative, current root server set — for all root queries.
• Refresh — When the cached root NS records expire (typically after 6 days based on their TTL), the resolver primes again. If the priming query fails, it falls back to the hints file to retry.

The hints file is therefore a safety net. It only matters at startup and when priming fails. As long as the resolver can successfully prime, the hints data is superseded by fresh authoritative data from the root.

Keeping root hints current

Although priming compensates for stale hints, operators should still keep the hints file reasonably up to date. Here's why and how:

• Why update — If a root server's IP address changes and the hints file is very old, the resolver might try to reach addresses that no longer work. Priming can still succeed as long as at least one hint address is valid, but fewer working addresses reduce resilience during startup.
• How often — Root server IP address changes are rare (a handful of times per decade). Checking the hints file annually is generally sufficient.
• How to update — Download the latest named.root from IANA's InterNIC site and replace the existing file. Most resolver packages also update the file as part of their software update process.
• Validation — Compare the file's serial number or modification date with the version currently in use. Some operators also verify the file's signature or checksum if published.

Modern resolver software (BIND, Unbound, Knot Resolver) ships with a current hints file and updates it during package upgrades. Operators running custom configurations should verify the file is not being left behind.

Further reading

IANA publishes the canonical root hints file and the list of root server identities. RFC 9609 defines the current priming process that uses root hints as its starting point. RFC 7720 documents the root name service protocol requirements.