Hiya. On Wed, Nov 09, 2016 at 01:11:16AM +0000, Baird, Josh wrote: > Hi Ray, > > I'm not quite sure why you would have your caching servers forward to > other DNS servers (Google, OpenDNS, etc). I would enable recursion > on them and would not forward anything. I would also consider > making these caching servers at each location slave your *internal* > authoritative zones (or views) to override recursion.
A couple thoughts on this: 1) The external caches tend to be pretty "close" latency wise and presumably have a very large cache to pull from. My belief is we'd probably see lower average response times for queries *not* already cached this way.... 2) Security folks prefer external access to fewer IP's. Simpler red tape wise I guess. Thanks, Ray > > As you stated, you can keep your AD DNS servers authoritative for > your AD domains and point your AD clients directly to these servers. > They can be configured to forward to your BIND environment which > performs recursion and resolution for non-AD 'internal' > domains/views. You can also configure your BIND 'internal' caching > servers to slave your AD zones as well. > > Cheers, > > Josh > > -----Original Message----- > From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Ray > Van Dolson > Sent: Tuesday, November 8, 2016 7:10 PM > To: bind-users@lists.isc.org > Subject: Enterprise DNS Architecture - AD and BIND > > Greetings; > > Am reviewing our DNS setup which has organically evolved over the > years and most certainly is due for an update: > > - We have AD servers responsible for our primary domain (internally). > > - We have other sets of AD servers responsible for other domains in > DMZ's and such. > > - We have a BIND Master/Slave pair acting as a hidden master for > external zones as well as doing split view for some of those same > zones where we want to return "non-public" IP's for queries that > would otherwise be answered with an external address. > > - We have multiple BIND caching servers. Some at remote sites that > handle split duty for Internet resolution (enabling accurate > geolocation for Internet based services -- our own included) and > internal lookups. > > In some cases, these "remote" caching servers need to forward lookups > to other "super" caching servers which have more privileged access to > the authoritative servers listed above... there are about a dozen of > these zones. > > They do static-stub zones for the AD managed zones. > > Another challenge is when clients point to them directly, Dynamic DNS > (RFC2136) doesn't work. Theoretically we could make BIND handle this > and forward on to AD, but adds complexity. > > The caching servers also do RPZ. > > We're now wanting to add some additional logic to resopnd differently > to VPN clients for some of our VoIP technologies to send RTP over the > Internet vs. over a VPN tunnel... > > I'd like to make this all much simpler, avoid mixing roles of servers > and help guide us as we decide what servers to deploy where. KISS > principle I guess. > > In an ideal world, I could completely pitch the whole split view > thing (where rr.domain.com resolves differently for Internet clients > than for "internal" clients). I can't think of a good way to avoid > this complexity, however. > > What I'm thinking: > > - Have an AD server at every location we have a BIND server. This way > client machines talk DNS *only* to AD servers so Dynamic DNS & > friends work reliably. AD servers would then forward to BIND servers > as needed. > > + Alternative: Configure clients to do DNS updates via DHCP Option > 81, etc. instead of via Dynamic DNS. This would allow clients to > point at BIND and take advantage of Anycast for resiliency and I > avoid needing to figure out how to make BIND pass RFC 2136 > requests on from clients to AD reliably... > > - Caching Servers will be the same configuration no matter where they > are, and do the same things: > > + "." will forward out to OpenDNS or Google, etc. for Internet > lookups. > > + Will be a "slave" for all AD owned domains. Thought here is > better client response times and fewer issues w/ TTL and cache > and better resiliency... > > - Alternative: Leave these as static-stub, but now I made need > logic in Ansible or whereever to point to "nearby" AD servers > depending on where the BIND server lives to keep response > times low when things aren't cached. That or not care about > latency... > > + Will be a "slave" for all of the split-view zones (only for the > "internal" view). Could do static-stub here as well, but think > slave may serve us better for similar reasons as w/ AD. > > + I can introduce my split view zones for VPN here as well. I > haven't thought this one through fully yet, but am hopeful I > don't need to fully duplicate the zones above and could instead > forward queries from one view to another........ > > - Authoritative BIND Servers mostly stay as-is aside from needing to be > configured to send notify's out to caching servers and proper FW > access maintained for AXFR. > > Please pick this apart and let me know where I'm going astray. :) > > Thanks, > Ray _______________________________________________ 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
