Best Practices for Authoritative Servers
Kevin Darcy
kcd at chrysler.com
Fri Feb 1 02:41:13 UTC 2008
Mark Andrews wrote:
>> Mark Andrews wrote:
>>
>>>> Mark, that's really clever. Thanks!
>>>>
>>>> As for loops in the AXFR chain, I used to not see the value until a
>>>> post from Kevin Darcy in this very forum. (I'll just refer readers to
>>>> the list archive, since I can't find the original post.) Basically,
>>>> what happens if the primary master goes down in the middle of
>>>> processing zone transfer requests from two slaves, such that one slave
>>>> has it and the other does not? Having the slaves use each other as
>>>> backup master ensures that the updated zone makes it to the other slave.
>>>>
>>>>
>>> Sure it helps get the latest zone out there. It also breaks
>>> the failsafe that was built into the design of the DNS.
>>> You don't want the SOA/IXFR query to the slave to reset the
>>> expiry timer.
>>>
>>> For the example about resetting the expire timer on change
>>> would be reasonable but not on every SOA/IXFR query that
>>> is answered by the slave.
>>>
>>>
>>>
>> I don't understand: why would answering SOA/IXFR reset a slave's expiry
>> timer?
>>
>>
>> - Kevin
>>
>
> When a slave performs a refresh query (SOA/IXFR) and the
> current SOA serial is returned the expiry and refresh timers
> are re-started. This happens regardless of whether the
> slave queried the master or another slave.
>
Thanks for straightening that out. I was misreading your earlier message
as saying that the act of *answering* a query would reset the expiry
timer. But of course you are correct: a set of "cross-connected" slaves
can keep refreshing each other and make the zone "immortal". This is not
an issue for the vast majority of our zones, since when a zone is
decommissioned from our master, our homegrown configuration-control
system will automatically remove the zone definitions from all of our
slaves. But, we have a few zones here and there that we slave from
business partners, and we've occasionally run into problems with the
master becoming unavailable and the cross-connected slaves continuing to
serve up a stale version. I'll have to put more thought into how to
prevent that from happening.
> If you have a loop in the axfr transfer graph all the slaves
> in that loop will converge to serving the same zone content
> (good) but will also keep resetting the refresh (with refresh
> not retry which is bad) and expiry timers (extremely bad)
>
It's a shame BIND doesn't have any way of differentiating between "peer"
masters and "upstream" masters, so that the resetting behavior can be
controlled.
- Kevin
More information about the bind-users
mailing list