Tuning for lots of SERVFAIL responses
marka at isc.org
Fri Feb 19 03:04:55 UTC 2016
In message <CAGYMsbuXuNBgOciqkS8f-DDVYwv9N6EaL4OS4J3yyXxqUgbbZg at mail.gmail.com>, John Miller writes:
> >> 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?
You list the servers you want the rest of the world to query. If it
is just a internal zone then you can just list all the servers.
> 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.
You can do this all locally to a site. NOTIFY and IXFR daisy chain.
Adding a new server to a also-notify list is not hard.
> 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
You just copy over a named.conf, perform local modes if required
and start named. Add NS/also-notify as appropriate. This isn't
hard to do.
> Another question: Is it just the master and slave zone types that
> bypass the recursive-clients limit?
They don't bypass. The query gets answered without needing to recurse.
> Presumably forward and stub types
> still come up against the limit b/c BIND still has to track a backend
> connection somewhere.
Yes, they require recursion if the answer isn't in the cache.
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the bind-users