Enterprise DNS Architecture - AD and BIND

Wed Dec 14 01:36:36 UTC 2016

Since this thread is still fresh, what is the current best practice
when slaving from AD? Do you pick one DC and list it as master or is
it safe to list multiple? We are looking to do the same and just
started the conversation with our AD team. The serial numbers among
DCs authoritative for the same zone are quite spread out and it takes
a few minutes for the DC with the lowest number to catch up. I'm not
sure if I can assume that two DCs with the same serial number have the
same zone contents. Haven't done a zone transfer comparizon yet.

Curious to know what your experience is when slaving from AD.

Thank you,
Slava

On Fri, Nov 18, 2016 at 12:29 PM, Darcy Kevin (FCA)
<kevin.darcy at fcagroup.com> wrote:
> Same here. Slave the AD zones, all end-user machines use BIND-based (Infoblox) servers for resolution, on Anycast addresses. DHCP servers (also Infoblox) update DNS for the clients, with the client names being registered in non-AD zones (some of which are defined by geography, with a generic "catch-all" for clients not designated as belonging to one of those geo-defined zones).
>
> If we *really* wanted to maintain client names in AD zones, Infoblox has an add-on product that would allow us to manage everything "from a single pane of glass", as the marketing folks say. But we haven't come up with a really compelling business case for registering them in AD zones, yet. Registering them where they are currently, works fine for us, given how our Suffix Search Lists, etc. are set. Microsoft subtly deprecates this setup by referring to it as a "disjoint namespace" in their documentation (PHBs don't like to hear architectures being described as "disjoint"), but it is fully supported by Microsoft at the infrastructure level (apps which make stupid assumptions might be a different story), so don't let their terminology scare you.
>
>                                                                                                                         - Kevin
>
>
> -----Original Message-----
> From: bind-users [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Barry S. Finkel
> Sent: Friday, November 18, 2016 10:29 AM
> To: bind-users at lists.isc.org
> Subject: Re: Enterprise DNS Architecture - AD and BIND
>
>
> 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
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users