Okay, so my named process rejecting my slave files during start up does
not represent a new feature of the newer code -- that's a relief.
Now, considering the observed behavior to be improper, I see my expiry
was too short. Since my files were older than my expiry, I guess that
explains it.
But that leaves two questions:
- Why didn't my log files include a message indicating the zones were
being rejected due to expiration?
- Does anyone know where the start up behavior is documented online?
Thanks.
--
Gordon A. Lang
----- Original Message -----
From: "Barry Margolin" <bar...@alum.mit.edu>
Newsgroups: comp.protocols.dns.bind
To: <comp-protocols-dns-b...@isc.org>
Sent: Thursday, August 26, 2010 9:31 PM
Subject: Re: named start-up behavior
In article <mailman.446.1282839053.15649.bind-us...@lists.isc.org>,
"Gordon A. Lang" <gl...@goalex.com> wrote:
I have not been able to locate documentation defining the named
start-up behavior. I am particularly interested in zone loading
for slave zones. Is this information available online?
For example, what if none of the listed masters are reachable at
the time of start-up? How frequently and for how long is it
retried? Can this be tweaked? Can the data on disk (if present)
be used as an interim better than nothing source?
The SOA Retry, and Expire timers control how frequently BIND will retry
failing zone transfers and how long they be retried.
If my memory isn't failing me, I thought the old BIND code used
disk data for slaves before zone transfers -- can anyone confirm
or refute this? Can anyone explain why a slave should never load
from disk (in the event of a zone transfer failure)?
That's exactly what happens. What do you think the file is for, if not
to load it at startup?
BIND uses the file's timestamp to schedule the refresh timer. So if the
SOA Refresh time is 6 hours, and the file is 1 hour old when BIND starts
up, it will schedule a zone transfer for 5 hours later.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
