Updating a resolving proxy DNS server's list of root content DNS servers.

You've come to this page because you've asked questions similar to the following:

Do I need to ensure that my resolving proxy DNS server's list of the "." content DNS servers is kept current ? If so, how and when do I do that ?

This is the Frequently Given Answer to those questions.

Yes, you need to ensure that the information that your resolving proxy DNS server has remains current. The list of "." content DNS servers changes over time.

The frequency with which you need to periodically refresh the information that your server has depends from which root server organization you have chosen to subscribe to. Some organizations have server lists that remain relatively static over periods of several years. For example: Some recent changes to the list of ICANN's "." content DNS servers were on 2017-10-24, 2016-03-23, 2015-12-01, 2007-11-01, 2004-01-29, 2002-11-05, and 1997-08-22; and this is not even a complete list. However, even if you are using an organizations whose list does change frequently, you shouldn't need to perform a refresh more often than twice per year.

How you update the list depends from what proxy DNS server software you are using.

What you do if you use The Internet Utilities

Use the dnsgetns command that is supplied as part of the package to obtain the list of IP addresses of the "." content DNS servers, from the DNS database itself (via your resolving proxy DNS server), and direct its output to a file. If the command exits with a success status, move that file to the Content\@ file in the working directory of your resolving proxy DNS server:

dnsgetns /b+ . > Content\Temp.@ && move Content\Temp.@ Content\@

Any changes will take effect immediately.

What you do if you use Dan Bernstein's djbdns

Use a command pipeline to obtain the list of IP addresses of the "." content DNS servers, directing its output to the $DNSCACHE_SERVICE_DIR/root/servers/@ file, then restart the dnscache service:

cd $DNSCACHE_SERVICE_DIR
dnsip `dnsqr ns . | awk '/answer:/ { print $5 ; }' | sort` > root/servers/@
svc -t .

If you intend to create more dnscache services using dnscache-conf in the future, update the /etc/dnsroots.local file as well:

dnsip `dnsqr ns . | awk '/answer:/ { print $5 ; }' | sort` > /etc/dnsroots.local

What you do if you use ISC's BIND

BIND employs a "root hints" file. This is not a list of the "." content DNS servers. It is a list of servers that publish such a list. BIND queries the servers listed in the "root hints" file at startup in order to find the actual list of "." content DNS servers. Therefore, BIND will still operate even if only one of the servers listed in the "root hints" file is correct.

Either obtain the information from the public DNS database using dig, or obtain a preprepared "root hints" file.

Several root server organizations publish the lists of their "." content DNS servers preprepared in BIND's "zone" file format, suitable for directly replacing one's existing "root hints" file:

• ORSC's "root hints".
• ICANN's "root hints".

Alternatively, you can using the dig command, that is supplied as part of the package, to generate a "root hints" file. This is done by instructing dig to perform a "NS" query for ".", and redirecting its output (which is in BIND's "zone" file format) to file.

Unlike dnsgetns, dig will not perform the extra lookups for the "glue" resource records, and you are thus relying upon upon the server that it queries to provide them as additional section resource records in order for your "root hints" file to be generated correctly. Therefore you must explicitly point dig at a "." content DNS server, rather than let it use the default (which will be your proxy DNS server).

If you are using the ORSC "." content DNS servers, this will be one of the [a-m].root-servers.orsc. servers:

dig @m.root-servers.orsc. ns . > db.cache.tmp

If you are using the ICANN "." content DNS servers, this will be one of the [a-m].root-servers.net. servers:

dig @m.root-servers.net. ns . > db.cache.tmp

Once you have obtained the list, replace your current "root hints" file with that file and restart BIND (either by sending it a "hangup" signal, or by using the rndc command):

mv db.cache.tmp db.cache
rndc reload

What you do if you use Microsoft's DNS server

Like BIND, Microsoft's DNS server employs a list of "root hints". This is not a list of the "." content DNS servers. It is a list of servers that publish such a list. Microsoft's DNS server queries the servers listed in the "root hints" at startup in order to find the actual list of "." content DNS servers. Therefore, Microsoft's DNS server will still operate even if only one of the servers listed in the "root hints" is correct.

Several root server organizations publish the lists of their "." content DNS servers preprepared in BIND's "zone" file format:

• ORSC's "root hints".
• ICANN's "root hints".

Microsoft's DNS server understands enough of BIND's "zone" file format to decode the usual forms of preprepared "root hints" files, and thus can use these preprepared lists. Move the file, after obtaining it, to %SystemRoot%\System32\Dns\Cache.dns, and restart Microsoft's DNS server.

What you do if you use MaraDNS

Use a command pipeline to obtain the list of IP addresses of the "." content DNS servers:

askmara N. | awk -F '|' '/^N/ { print $3 }' | while read i ; do
	askmara A$i | awk -F '|' '/^A/ { print $3 }'
done

Then edit the appropriate ipv4_alias assignment in your mararc file, replacing the existing list of IP addresses with the new list, with the elements separated by by commas:

ipv4_alias["whatever_root_organization_you_chose"] = "10.53.0.1,10.53.0.2,10.53.0.3"
root_servers["."] = "whatever_root_organization_you_chose"

Finally, shut down and restart the MaraDNS dæmon.