-
Print
-
DarkLight
-
PDF
Root hints - a collection of operational and configuration FAQs
This collection of FAQs (and links to other related articles) aims to de-mystify for new DNS administrators, what the root hints are and how they are used.
What are the root hints?
The root hints are a list of the servers that are authoritative for the root domain ".", along with their IPv4 and IPv6 addresses. In other words, this is a collection of NS, A, and AAAA records for the root nameservers.
Why do we need root hints?
When handling a client query for which it has no answer, a recursive server needs to know which authoritative server is responsible for the domain of the name it has been asked to resolve. So for example, if a client queries for hostname.example.com, a recursive server that has just been restarted will not know where to find the authoritative servers for example.com, nor the authoritative servers for com. It will need to start at the 'top', which it does by sending the query for hostname.example.com to one of the root nameservers.
What is root priming?
There is a subtle clue in the name we give the root hint zone - the word 'hint'. Although the names and addresses for the root nameservers don't change very often, there are occasional updates. Thus the root hint zone is assumed to be mostly accurate, but it is not treated as the authoritative list of the roots. Instead, named will query the servers in the root hints list in turn, asking them for the NS records for ".". When an authoritative response is received, the answer is added to cache, and it is the newly primed set of root nameservers that is used, rather than the set from the hints file.
Do I need to configure a root hints zone myself?
In most cases, no. All modern and supported versions of BIND are delivered with a built-in zone for "." of type 'hint'. It's in lib/dns/rootns.c. We update it periodically, for example, to add an AAAA for D root a few years ago, and did so again when the H root address changed on 1st December 2015. Changes are usually included in the next versions of BIND to be released following the update to the root nameserver set.
It is only installations that are completely separate from the Internet name space who need to configure their own private set of root nameservers.
Doesn't the built-in root hint zone get out of date?
It doesn't matter if the root hint zone is a little out of date - this is because root priming takes care of any recent changes and makes sure that the most recent authoritative data is obtained and loaded into named's cache. It is the set of root servers obtained as a result of root priming that is actually used for resolution of client queries. As long as at least one of the servers listed in the root hint zone is still correct, named will be able to prime itself.
I keep seeing warnings in my logs from checkhints - what should I do about them?
These warnings occur during root priming to inform the DNS server administrator that their copy of the root hints file is out of date. For example, when D root changed its address, anyone running BIND with an older version of the root hints would have seen warnings like these being logged:
10-Aug-2013 14:27:37.216 general: warning: checkhints: d.root-servers.net/A (199.7.91.13) missing from hints
10-Aug-2013 14:27:37.216 general: warning: checkhints: d.root-servers.net/A (128.8.10.90) extra record in hints
These warnings are harmless.
- If using built-in roots you can ignore the warnings (and should plan to upgrade to a more current version of BIND when available).
- Administrators relying on built-in root hints who want to eliminate the warnings right away could, if they choose, update the built-in roots in lib/dns/rootns.c by hand, rebuild BIND, and then run the new named binary until they are able to upgrade.
- Administrators using their own root hint zone should update it manually.
For more details about this bug, see: Why is BIND re-priming the roots from hints more often than it should?.
The additional re-priming queries should not adversely affect your server's recursive performance and administrators will be unaware that they are occurring unless they are seeing checkhints warnings in their logs. Note particularly that a resolver will only need to send queries to the root nameservers for a TLD that is not already in cache. This in theory could cause re-priming at a frequency of up to once per second, but with a 'warm' cache would be significantly less.
When does root priming occur after starting named?
Root priming is done for the first time, only when named needs to send a query to one of the root nameservers. If your nameserver never needs to do this, then the roots will never be primed. For example. recursive nameservers that are configured with a global forwarders list and the option 'forward only;' should never need to send queries to the root nameservers directly, so wouldn't be expected to initiate root priming.
Does named ever refresh the primed roots?
Yes - named will re-prime the roots that it has in cache if and when the last authoritative server for "." expires or is otherwise removed from cache. Reasons why named may no longer have a set of authoritative servers for "." in cache include:
- The records originally obtained by priming have expired (reached the end of their time to live - TTL). Priming is initiated to refresh the roots.
- Sometimes it happens that a recursive server 'learns' a new RRset for the root servers as a result of something like an upward delegation by an old DNS server. Clearly this information is not as trustworthy as the list of root nameservers obtained directly from the root nameservers themselves - so just in case, named goes back and re-primes its list.
- The records are deleted from cache because the cache size limit has been reached, and the Least Recently Used (LRU) algorithm has selected the roots and removed them to make space for new entries that need to be added to cache.
It can also happen that the root nameservers in cache expire or are overwritten with less-authoritative records singly or as a subset of the full set of servers. This situation surprises some administrators or DNS users, and is explained in When I do a "dig . ns", many of the A records for the root servers are missing. Why?.
Do all BIND nameservers do root priming?
You can start named with built-in or manually-configured root hints and they will never be used at all if:
- Your nameserver is authoritative-only and never needs to make any recursive queries (but see: Why does my authoritative-only nameserver try to query the root nameservers?).
- You are running a nameserver that exclusively uses forwarding to resolve all client queries.
- You are running a recursive nameserver that never receives any queries at all (this last one included for completeness only - we are not sure why you would be running a recursive nameserver that does not receive any queries).
The first time named needs to resolve a client query or to look up a nameserver that it needs to contact (as part of managing its authoritative zones) it will always initiate root priming.
Can having only a few root servers in cache cause problems?
In most cases no. What happens is that named will re-prime the root server list as and when needed.
If it then happens that all of the IPv4 root nameserver records have expired from cache, but the IPv6 records remain, then named will not yet refresh via re-priming because it believes that it still has servers that are contactable. This situation will persist until the IPv6 server records have also been removed from cache.
(The same scenario is possible with other domains that advertise both IPv4 and IPv6 addresses for their authoritative servers.)
Do I need a root hint zone if I'm using global forwarding?
BIND expects there to be a root hint zone, even if it doesn't need to use it.
If you want to use a combination of global forwarding and direct queries for specific domains, we recommend that you use forward zones or static stub zones to override the global forwarding settings rather than falling back to resolving queries by following delegation from the root nameservers. For more details on this please read: How can I disable global forwarding for delegated subdomains? and I want to forward all DNS queries from my caching nameserver to another server but configure exceptions for some domains - how?.