I wouldn't be overly concerned about your recursive boxes being authoritative for your internal (only) zones. You already have mechanisms in place to prevent external clients from using them for recursive services.
On Tue, Sep 6, 2016 at 3:20 PM, That One Guy /sarcasm < thatoneguyst...@gmail.com> wrote: > Im putting our recursive sservers up for our network to use, theyre access > limited by ACL and external router firewall policies to our networks only > > There will be four total servers NS1 and NS2 are our current authoritative > only servers, they are public facingfor our domains and our ARIN allocation > > I read many conflicting best practices, so ... > > NS3 and NS4 I am tempted to make slaves to NS1 (its the master for all > zones) and put our RFC 1918 space on NS1, however this creates a security > dilema in that a new bind vulnerability could expose our internal space > structure, not that its a huge deal today, I would prefer to not have made > a poor choice for ease today that causes a problem down the road. > Im tempted to delegate a subdomain (infrastructure.domain.com or > whatever) to NS3 for rfc1918 record, but then that puts authoritative > master zone records on a recursive server which all the best practices > suggest avoiding. > > I suppose i can put forwarders in for this up to NS1/2 on the recursive > servers and use bind views to limit the internal zones > > > What is recommended in this scenario? > > Also, with a set of recursive servers, is it possible to sync the cache > between the two so I can load balance the servers (we wont likely ever have > enough load from our network for it to ever be an issue) > > -- > If you only see yourself as part of the team but you don't see your team > as part of yourself you have already failed as part of the team. >
