<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 21, 2018 at 8:18 AM, Tony Finch <span dir="ltr"><<a href="mailto:dot@dotat.at" target="_blank">dot@dotat.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Evan Hunt <<a href="mailto:each@isc.org">each@isc.org</a>> wrote:<br>
><br>
> One thing to keep in mind, though, is that the two services will share each<br>
> other's fates.  If I were deploying a really big high-traffic server, I<br>
> might consider whether I wanted my recursive service to have to wait for<br>
> all the zones to load before it could function, or whether I wanted to have<br>
> to update my authoritative server because it was vulnerable to a crash bug<br>
> in the recursive code.<br>
<br>
</span>On our recursive servers we have authoritative copies of all our local<br>
zones so that they can give answers for on-site stuff even when bits of<br>
the network are broken. (Downstream validating resolvers will probably be<br>
out of luck tho.) This is about 70 zones, average size about 2MB, biggest<br>
about 30MB. But, we also have RPZ and the biggest blocklist is about half<br>
a gig and this dominates the startup time (it takes nearly 20 seconds).<br>
This isn't an availability problem, tho, because the recursive servers are<br>
in an HA cluster using keepalived and the health checker won't bring a<br>
node into service until it has finished starting.<br>
<br>
Our authoritative servers are separate. Probably the main reason for not<br>
turning them into views on the recursive servers is that the auth servers<br>
have to be more exposed to attack from the Internet. Our recursive servers<br>
can do things like firewall off external TCP connection attempts, to avoid<br>
connection pool exhaustion attacks. I've done less HA engineering on our<br>
auth servers, and I'm relatively relaxed about patching them, because I<br>
(foolishly?) trust other resolvers out on the Internet to make effective<br>
use of my secondaries.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tony.<br>
--</font></span></blockquote><div><br></div><div>Likewise.  My resolvers are stealth slaves for all my zones.   Mainly because they get updates faster - users do not have to wait for the old data to expire its ttl before the resolver gets the new data.  Also, there is no chance of cache poisoning for my zones, since they are slaved, not cached.<br></div><div><br></div><div>-- <br></div><div>Bob Harold<br><br></div></div></div></div>