Evan Hunt <e...@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 <d...@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. _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
