Multiple AD domains

Darcy Kevin (FCA) kevin.darcy at fcagroup.com
Fri Jul 29 21:38:38 UTC 2016


You could remove the GSS-TSIG dependency by using a non-Microsoft-based DHCP server and having it update DNS instead of the clients updating themselves.

It just so happens that the same consortium that maintains BIND (reference implementation of DNS) also maintains the reference implementation for DHCP…

I realize (from personal experience) that sweeping changes to an enterprise’s DHCP infrastructure can be, depending on size/complexity/diversity of the environment in question, much easier said than done – updating relays/”helpers”, firewall rules, failover/latency considerations, etc. But you might want to consider your long-term strategic goals. If you co-locate your DNS and DHCP on the same servers, for instance, you position yourself well for an eventual evolution to an appliance-based DNS/DHCP approach (e.g. Infoblox or its competitors).

                                                                                                                                                                                                                                - Kevin

[FCA_Pantone_email]
----------------------------------------------------------------------
Kevin Darcy
NAFTA Information Security Projects

FCA US LLC
1075 W Entrance Dr,
Auburn Hills, MI 48326
USA

Telephone: +1 (248) 838-6601
Mobile: +1 (810) 397-0103
Email: kevin.darcy at fcagroup.com

From: Vinícius Ferrão [mailto:ferrao at if.ufrj.br]
Sent: Thursday, July 28, 2016 10:03 AM
To: Darcy Kevin (FCA)
Cc: bind-users at lists.isc.org
Subject: Re: Multiple AD domains

I agree with using BIND as the default DNS server even on Active Directory environments. Windows DNS on 2012 R2 is still very bad and lacks basic features like disabling external recursion. This should change on Server 2016 but I will stay with BIND.

Another thing that I would like to add to this thread is about completely ditching Windows DNS and use BIND as the master zone for AD. The default procedure is just creating the AD sub zone on BIND as master and allowing IP updates during the installation of AD. Since IP based updates are insecure, GSS-TSIG is used with Kerberos after the AD install. This is how we roll on our University.

But we are a facing a similar issue. We would like to have a single DNS managing two distinct (and without trusts) AD domains. Using IP based updates would work as expected with the two different zones, but we are screwed with the Kerberos Tickets and the keytabs. Since BIND does not allow multiple keytabs I really don't know what to do. If someone have an idea to solve this I will be very grateful.

Thanks in advance,
V.

Sent from my iPhone

On Jul 27, 2016, at 16:34, Darcy Kevin (FCA) <kevin.darcy at fcagroup.com<mailto:kevin.darcy at fcagroup.com>> wrote:
My preference? Have all your clients use BIND to resolve DNS (this gives access to more advanced features like sortlisting, good query logging, blacklisting/redirection through the RPZ mechanism, Anycast, etc.). Set up the BIND instances as slaves for the AD zones, and have the AD folks add the BIND instances to the apex NS records so that the DCs will trigger fast replication to BIND via the NOTIFY extension to the protocol.

I’d never let a regular PC client use Microsoft DNS for resolving DNS. Perish the thought!

Note that this approach, if implemented simply, doesn’t scale to large numbers of BIND instances (because you don’t want to add dozens or hundreds of apex NS records to the zone). Beyond a certain threshold, you’d want to set up a multi-level slaving/NOTIFY hierarchy on the BIND side…

                                                                                                                                                                                                                - Kevin



<image001.jpg>
----------------------------------------------------------------------
Kevin Darcy
NAFTA Information Security Projects

FCA US LLC
1075 W Entrance Dr,
Auburn Hills, MI 48326
USA

Telephone: +1 (248) 838-6601
Mobile: +1 (810) 397-0103
Email: kevin.darcy at fcagroup.com<mailto:kevin.darcy at fcagroup.com>

From: bind-users [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Jeff Sadowski
Sent: Wednesday, July 27, 2016 3:00 PM
To: bind-users at lists.isc.org<mailto:bind-users at lists.isc.org>
Subject: Re: Multiple AD domains

should I setup 192.168.1.1 as slaves to these two domains would that fix it?

On Wed, Jul 27, 2016 at 12:56 PM, Jeff Sadowski <jeff.sadowski at gmail.com<mailto:jeff.sadowski at gmail.com>> wrote:
On the samba mailing list they described setting up the DC as the NS and forward to another machine for more rules.
This will work fine for one domain. Now lets say I have 2 domains.

If I setup forwarders like so on 192.168.1.1

zone "domainA" IN { type forward; forward only; forwarders { 192.168.2.1; }; };
zone "domainB" IN { type forward; forward only; forwarders { 192.168.3.1; }; };

It will cache entries for each domain and if a computer gets a different address for dhcp it will update on the domain's DNS but the dns on 192.168.1.1 will have a cached entry untill it expires.

192.168.2.1 and 192.168.3.1 are setup to forward all other zones than their domain names to 192.168.1.1

if I have DNS server set for all machines in domainA to 192.168.2.1 all machines on domainA see any DNS changes to domainA imediately machines on domainB are cached and can take time to clear out.
And
if I have DNS server set for all machines in domainB to 192.168.3.1 all machines on domainB see any DNS changes to domainB imediately machines on domainA are cached and can take time to clear out.

What is the best way to resolve this issue?

_______________________________________________
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<mailto:bind-users at lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160729/25e255b9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3764 bytes
Desc: image001.jpg
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160729/25e255b9/attachment-0001.jpg>


More information about the bind-users mailing list