Enterprise DNS Architecture - AD and BIND
Ray Van Dolson
rvandolson at esri.com
Wed Nov 9 01:15:34 UTC 2016
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-bounces at lists.isc.org] On Behalf Of Ray Van Dolson
> Sent: Tuesday, November 8, 2016 7:10 PM
> To: bind-users at 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
More information about the bind-users
mailing list