Tuning for lots of SERVFAIL responses

Mark Andrews 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
> quickly?

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.

> John
-- 
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 mailing list