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: The most
recent two changes to the list of ICANN's "." content DNS
servers were on 2002-11-05 and 1997-08-22. 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:

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:

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.

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.