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
namedbinary until they are able to upgrade. - Administrators using their own root hint zone should update it manually.
The warnings will be logged each time that named encounters the mismatch between its root hints and what it receives from the authoritative root nameservers. Since the TTL of these authoritative records is large, some administrators are surprised that they see the warnings more frequently than anticipated, sometimes in spates of many warnings, all in a short period of time. This is most likely due to named receiving a new set of root nameserver records in an upward referral from another server. When this happens, named cannot trust the new set because they have not come from one of the authoritative root nameservers, so it initiates a new root-priming event to ensure that it is using the correct set. (An upward referral is one in which a server that is unable to answer a query, usually because of an out-of-date delegation, responds with a referral to the root nameservers. This type of response is now discouraged as poor operational practice, but some older implementations still do this.)
Fixed in 9.12.0, 9.11.3, 9.10.7 and 9.9.12, bug RT #45241 could cause named to send unnecessary and frequent priming queries. This re-priming can occur no more frequently than once per second due to the way BIND holds learned NS/A/AAAA RRsets during processing of client queries in case they need to be re-used, and in most cases would be seen less often than this.
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.
If you take a network packet trace of recursive server that has just been started up you will notice that on receipt of the first client query that requires recursion, named will do two things in parallel. The first is that it will initiate a 'best effort' attempt to try to get an answer for the client. Since it does not yet have a primed set of roots, it will send the client query to one of the root hint servers. At the same time, root priming is initiated (as a separate task.
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,
namedgoes 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.
This is not necessarily a bad thing - it depends on what your nameserver is being used for. Having the roots deleted from cache and having to re-prime them very frequently and soon afterwards suggests that the configured cache size is too small for the rate and breadth of the query load that the server is handling and you should consider increasing your provisioning. Having the roots deleted from cache, but not needing to prime them again soon, would be an indication that they are seldom needed - very likely because when handling new client queries, named already has in cache a list of the servers authoritative for the TLD within which the domain name being queried falls.
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.
We are aware of one rare corner case where a partial set of root nameservers can cause resolution failures. This is one in which a recursive nameserver is running on a server that is IPv6-enabled but which has no genuine IPv6 connectivity, and whose DNS admins have not made configuration or run-time control changes to compensate for this. If this lack of connectivity is coupled with a failure of the socket layer to pass send failures back to the named application, then any attempts to send queries to IPv6 destinations will instead time out. In this situation, named treats those server addresses not as solidly unreachable, but simply very slow to respond.
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?.
There are some situations where the combination of root hints and forwarding may work well, and some where it will very definitely lead to unpredictable failures. It is important to consider whether the answers to queries will differ depending on the way they are obtained. If it's possible that different answers are obtained via the two different resolution methods (iteration versus forwarding), and that both are likely to be used in different circumstances to populate the same cache, then we strongly recommend that you do not implement this type of configuration.
When priming the roots, what is needed is a query response from a server that is authoritative for the root zone ".". If your configuration includes global forwarding, the query for the NS records for "." will be sent to the global forwarders instead of to the servers listed in the hint zone. The global forwarders may be authoritative for ".", or they may instead return a non-authoritative answer from their own caches. In this latter case, the answer will not be authoritative and named will need to try again (only to fail again, etc.).