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

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.


More information about the bind-users mailing list