Peaceful coexistence with Windows domain

Jeff Lightner jlightner at water.com
Fri Mar 13 13:35:13 UTC 2009


Well not a perfect solution but what we have done for records that need
to be seen inside and outside is simply create the zone in both Windows
DNS and BIND.  

In BIND we only have the stuff the outside world would see.
In Windows we have the stuff the internal users would see.   If the
internal users need to see external records then it must be added by the
Windows admins to the zone on the Windows DNS servers.

Here like there all lookups from internal clients go first to the
Windows DNS servers.  If they have the zone then they'll never send the
request to us which is why it must be duplicated there.   For all other
lookups the Windows DNS servers queries the BIND DNS servers.  On the
latter we allow recursive lookups for internal clients.   Also there are
many zones BIND DNS for our various brands that do not exist at all on
the Windows DNS server so all those request SHOULD come to us any way.

Of course you could do all this with views in BIND and take the zone
duplication out of Windows DNS and (Linux)/BIND.   I just implemented
views for those other brands because we had a need to have an internal
web server tested as it will be used for staging what goes to the
external web server.

-----Original Message-----
From: bind-users-bounces at lists.isc.org
[mailto:bind-users-bounces at lists.isc.org] On Behalf Of Kevin Darcy
Sent: Thursday, March 12, 2009 11:45 PM
To: bind-users at isc.org
Subject: Re: Peaceful coexistence with Windows domain

You mean, other than the fact that MS-DNS is an inferior DNS 
implementation and, as pointed out in the original post, would need to 
forward all queries for names outside of the AD zones?

 

                                             - Kevin


Ben Bridges wrote:
> > If I dump the delegation and make an MX record in the master, mail 
> will be
> > OK, but then no one can query records in that zone because it's not
> > actually delegated unless they point at MS-DNS.
> Is there a reason why you can't point all of your internal hosts (AD 
> and non-AD) at your AD's for resolution?
>  
>
>
------------------------------------------------------------------------
> *From:* bind-users-bounces at lists.isc.org on behalf of Peter Laws
> *Sent:* Thu 3/12/2009 4:51 PM
> *To:* bind-users at isc.org
> *Subject:* Peaceful coexistence with Windows domain
>
> Our environment includes a couple of AD servers.  They serve DNS to
PCs
> using AD (but not all PCs).  They allow DDNS for clients and slave the

> rest
> of our environment's zones.  For some reason, they *forward* every
other
> query to us, but never mind that.  Look it up your own damn ... well, 
> never
> mind.
>
> At any rate, we don't actually delegate "their" zone to them.  This
causes
> problems, as you can imagine.
>
> I'm told that the reason we're doing things this way is that we don't
want
> any of those "internal addresses" to be queried by the unwashed masses
> lurking outside our perimeter.
>
> So my thought was, well, let's delegate the zone to the AD servers.
Since
> they are already ACLed (or whatever MS calls it), no one will be able
to
> see "their" records off-campus but on-campus folks will be able to
> (finally) resolv addresses in that zone regardless of where they point
> (internally) for DNS.
>
> Except that they need an MX record for that zone.
>
> So adding the NS record to delegate the zone to them properly meant 
> that no
> one could see the MX from the outside (since the MS-DNS is ACLed).
>
> If I dump the delegation and make an MX record in the master, mail
will be
> OK, but then no one can query records in that zone because it's not
> actually delegated unless they point at MS-DNS.
>
> We thought of slaving that zone on the master, but then we run into
> security, who doesn't want any of that "internal information" leaked
out.
> No problem, since we're slaving the zone, we'll pop an ACL on it.
Problem
> solved!  Hurray.
>
> Except for that MX record.
>
> Once you delegate a zone, you *delegate* the zone.  The MX is
invisible.
>
>
> So my requirements are to 1) allow that MX record to be seen
"outside", 2)
> allow any host in our environment to be able to query names in any
zone
> regardless of which system they point at for DNS, and 3) not have any
> records in that zone be visible "outside" save for that MX.
>
> I'm assuming that switching our configuration to use views would help,
but
> we'd like to avoid that, at least for now.
>
> Any quick fixes?
>
> I checked, and per the MS-People, MS-DNS cannot put ACLs on particular
> records.  Neither can BIND, so no surprise there.
>
> Which rock do I need to look under?
>
> --
> Peter Laws / N5UWY
> National Weather Center / Network Operations Center
> University of Oklahoma Information Technology
> plaws at ou.edu
>
-----------------------------------------------------------------------
> Feedback? Contact my director, Craig Cochell, craigc at ou.edu. Thank
you!
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

_______________________________________________
bind-users mailing list
bind-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
 
Please consider our environment before printing this e-mail or attachments.
----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------



More information about the bind-users mailing list