Tuning for lots of SERVFAIL responses
John Miller
johnmill at brandeis.edu
Fri Feb 19 02:19:42 UTC 2016
>> I was going to respond with the same advice --
>> slave your internal zones -- but then I somehow convinced myself that "recurs
>> ive-clients" was merely the quota of concurrent RD=1 queries that named would
>> handle, thus slaving wouldn't help in a network-outage situation, since name
>> d would still drop any new RD=1 query whenever the quota was full.
>
> For some reason people are afraid to slave internal zones. Back
> when I was working for CSIRO I used to slave all the internal zones
> for all of the sites the division had. Each site administered its
> own zones but all sites slaved all of them. That way local and
> inter site lookups always succeeded even when the external links
> were down.
Something I just thought of: how did you manage your NS records in
this situation? To get NOTIFY/IXFR to work properly, either you have
to list every one of your recursive servers in your local NS records
or you have to do an also-notify block on the master. Or you just
skip the NOTIFY/IXFR altogether and set very low refresh values on
your zones! How did you handle standing up/taking down servers
quickly?
Another question: Is it just the master and slave zone types that
bypass the recursive-clients limit? Presumably forward and stub types
still come up against the limit b/c BIND still has to track a backend
connection somewhere.
John
More information about the bind-users
mailing list