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