Updating root zone file bind
Changes are usually included in the next versions of 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.
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.
When named starts, it needs certain information before it can respond to recursive queries, such as how to reach the root servers.
If named is configured to do DNSSEC validation, it also needs to have starting trust anchors.
In other words, this is a collection of NS, A and AAAA records for the root nameservers.
If your nameserver never needs to do this, then the roots will never be primed. 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.
BIND 9.6 and 9.7 included files with the same keys in a slightly different format.
We are not providing updated files for these releases as they are well past end-of-life.
Search for updating root zone file bind:
Assuming that the keys are not already expired (in which case named will log that the key is expired and validation will not work), named will use RFC 5011 to detect new keys and automatically roll and maintain keys.