other experiments

[Kevin Darcy]

Sorry Jay, but "named_dump.db" is just a dump file that gets created when you
request named to dump its database. Named never reads it. Delete that file and
named works just the same.

When you define a slave zone, you can optionally give it a file name. That is
where the slave copy (usually) is kept. And that's what named (usually) reads
to load the slave one when it (re)starts. (If you don't give it a file name,
then named has to do a zone transfer of the zone whenever it restarts. I can't
imagine anyone configuring their nameserver this way unless they enjoy slowing
down their restarts and wasting bandwidth).

The hints file, when configured, will be used for the initial root
NS "priming" query, unless global forwarding is in effect. If you are master,
slave or stub for the root zone, then it would be a configuration error to
also define the root zone as type "hint", so being master/slave/stub for root
is mutually exclusive with using a hints file. If you define a hints file and
global forwarding is in effect, it doesn't hurt anything, but it doesn't serve
any useful purpose either, since the root NS information from the forwarded
"priming" query effectively overrides the hints data. (You can see the
original hints data in a dump, but it is never actually used if real root
NS data is available).


- Kevin
Quadri, Jay wrote:

> I can now see after investigating; that that all slave zone on my NS is
> automatically cached (via zone transfer in to file called named_dump.db) as
> soon as I restart my NS, My NS will query the cache (named_dump.db) before
> interrogating the hints file for root server.   This is the answer I was
> expecting.