Enterprise DNS Architecture - AD and BIND

Barry S. Finkel bsfinkel at att.net
Fri Nov 18 15:29:22 UTC 2016


On Tue, 8 Nov 2016 16:09:36 -0800 Ray Van Dolson <rvandolson at esri.com> 
wrote:

> 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

When I was managing a mixed AD/BIND DNS complex, I had AD DNS only for
one forward zone and five /24 reverse zones.  NO user machine used any
AD DNS server as its DNS server; ALL machines queried the BIND
servers, which were slaves for the AD zones.  The rest of the AD domains
that were slaved were around eleven sets of AD "_" zones.

--Barry Finkel


More information about the bind-users mailing list