named start-up behavior

[Gordon A. Lang]

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" <barmar at alum.mit.edu>
Newsgroups: comp.protocols.dns.bind
To: <comp-protocols-dns-bind at isc.org>
Sent: Thursday, August 26, 2010 9:31 PM
Subject: Re: named start-up behavior


> In article <mailman.446.1282839053.15649.bind-users at lists.isc.org>,
> "Gordon A. Lang" <glang at 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, barmar at 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>