questions on allow-query

Tony Finch dot at dotat.at
Wed Feb 21 13:18:09 UTC 2018


Evan Hunt <each at isc.org> wrote:
>
> One thing to keep in mind, though, is that the two services will share each
> other's fates.  If I were deploying a really big high-traffic server, I
> might consider whether I wanted my recursive service to have to wait for
> all the zones to load before it could function, or whether I wanted to have
> to update my authoritative server because it was vulnerable to a crash bug
> in the recursive code.

On our recursive servers we have authoritative copies of all our local
zones so that they can give answers for on-site stuff even when bits of
the network are broken. (Downstream validating resolvers will probably be
out of luck tho.) This is about 70 zones, average size about 2MB, biggest
about 30MB. But, we also have RPZ and the biggest blocklist is about half
a gig and this dominates the startup time (it takes nearly 20 seconds).
This isn't an availability problem, tho, because the recursive servers are
in an HA cluster using keepalived and the health checker won't bring a
node into service until it has finished starting.

Our authoritative servers are separate. Probably the main reason for not
turning them into views on the recursive servers is that the auth servers
have to be more exposed to attack from the Internet. Our recursive servers
can do things like firewall off external TCP connection attempts, to avoid
connection pool exhaustion attacks. I've done less HA engineering on our
auth servers, and I'm relatively relaxed about patching them, because I
(foolishly?) trust other resolvers out on the Internet to make effective
use of my secondaries.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Rockall: Southerly, 5 at first in far southeast, otherwise 6 to gale 8,
increasing severe gale 9 at times, veering westerly 5 or 6 later in northwest.
Rough or very rough, occasionally high in northwest. Rain or showers. Moderate
or good.


More information about the bind-users mailing list