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.
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:
[C:\SERVICES\DNSRCPD\]dnsgetns /b+ . > Content\Temp.@ && move Content\Temp.@ Content\@ [C:\SERVICES\DNSRCPD\]
Any changes will take effect immediately.
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 /var/service-bundles/services/dnscache/service #printf '%s\n' $(dnsip $(dnsns .)) > root/servers/.@.tmp /var/service-bundles/services/dnscache/service #mv root/servers/.@.tmp root/servers/@ /var/service-bundles/services/dnscache/service #svc -t .. /var/service-bundles/services/dnscache/service #
This is using the convenience utilities that are in djbwares version 11 and later.
That version of djbwares is IPv6-capable, and its dnsip will print multiple IP addresses on a single line.
The ICANN "." content DNS servers all nowadays have both IPv4 and IPv6 addresses, a process that began in 2008.
The use of printf '%s\n' is a standard Unix idiom for separating these addresses onto individual single lines.
The use of .@.tmp is not necessary for dnscache, which does not re-read the @ file once it has started. It is to avoid losing the original @ file should a network outage or something cause the two lookup tools to fail.
For older versions of djbwares, and vanilla Bernstein djbdns, a little use of awk and (optionally, even) sort achieves much the same result.
If you intend to create more dnscache services using dnscache-conf in the future (which djbwares does not include, service management systems long-since having gained instructions of their own on how to create dnscache services), update the /etc/dnsroots.local file as well:
~ #dnsip `dnsqr ns . | awk '/answer:/ { print $5 ; }' | sort` > /etc/dnsroots.local.tmp ~ #mv /etc/dnsroots.local.tmp /etc/dnsroots.local ~ #cd $DNSCACHE_SERVICE_DIR /service/dnscache #dnsip `dnsqr ns . | awk '/answer:/ { print $5 ; }' | sort` > root/servers/.@.tmp /service/dnscache #mv root/servers/.@.tmp root/servers/@ /service/dnscache #svc -t . /service/dnscache #
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:
Alternatively, you can use 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 or the dnsip $(dnsns .) combination, 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:
~ #cd /etc/bind /etc/bind #dig @m.root-servers.orsc. ns . > db.cache.tmp /etc/bind #
If you are using the ICANN "." content DNS servers, this will be one of the [a-m].root-servers.net. servers:
~ #cd /etc/bind /etc/bind #dig @m.root-servers.net. ns . > db.cache.tmp /etc/bind #
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):
/etc/bind #mv db.cache.tmp db.cache /etc/bind #rndc reload /etc/bind #
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:
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.
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.