Multiple AD domains

[Jeff Sadowski]

Correct on the gist. All answers where extremely helpful. I am curious
on Vinícius
Ferrão query I would like it to be more secure. I'll have to read more on
using GSS-TSIG with Kerberos. I seem to recall this is setup by the samba
install of AD but I'll have to look at it more closely as now I want to
setup a slave DNS to the AD's DNS. I too will probably have the same issue
as Vinícius Ferrão.
Is the only good option for now to leave my server mostly open with
accepting from an ip which can be spoofed (I'm just doing this on a
computer that is unlikely to get hacked with a spoof) but I would like
something that I could take to business security. The only domains I
have vulnerable are just a few test ones that I can rebuild in a heartbeat.

On Thu, Jul 28, 2016 at 1:40 PM, Darcy Kevin (FCA) <kevin.darcy at fcagroup.com
> wrote:

> Yes, I did misread the original post; thanks for clarifying.
>
>
>
> But, the gist of the question seemed to be about mitigating the effects of
> caching, for dynamically-changing data. At a high level, whether the zones
> are AD zones or not, whether the “master” is BIND or Microsoft DNS, doesn’t
> have a whole lot of bearing on that challenge. As should be obvious from
> what I proposed, I prefer the slaving+NOTIFY approach over setting up
> fragile forwarding arrangements.
>
>
>
> The other sledgehammer approach, of course, is to set the TTLs really low,
> but that can have a disastrous effect on performance/capacity, according to
> how frequently the dynamically-changing names are being queried. Of course,
> no amount of named.conf tweaking will help to mitigate the effects of
> caching that occurs on the clients themselves (e.g. “nscd” on some *nix
> platforms, Windows resolver cache for Windows). The only standards-based
> solution for that is to lower the TTLs. (Non-standards-based solutions
> include ugly stuff like running a script on every client to flush the cache
> every minute, ugh). But, as always, lowering TTLs, should be done, if at
> all, with one’s eyes open to the performance/capacity impact.
>
>
>
>
> - Kevin
>
>
>
>
>
>
>
> [image: 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:* Chris Buxton [mailto:clists at buxtonfamily.us]
> *Sent:* Thursday, July 28, 2016 12:52 PM
> *To:* Darcy Kevin (FCA)
> *Cc:* bind-users at lists.isc.org
>
> *Subject:* Re: Multiple AD domains
>
>
>
> The OP's question was about setting up BIND, not MS DNS, related to using
> Samba, not Windows, as the domain controller.
>
>
>
> Regards,
>
> Chris
>
> Sent from my iPhone
>
>
> On Jul 27, 2016, at 12:36 PM, Darcy Kevin (FCA) <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
>
>
>
> *From:* bind-users [mailto:bind-users-bounces at lists.isc.org
> <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
> *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>
> 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
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160728/f1a9dbc9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3764 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160728/f1a9dbc9/attachment-0001.jpg>