<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>

<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7651.59">
<TITLE>Peaceful coexistence with Windows domain</TITLE>
</HEAD>
<BODY>
<DIV id=idOWAReplyText12381 dir=ltr>
<DIV dir=ltr><FONT size=2>> If I dump the delegation and make an MX record in 
the master, mail will be<BR>> OK, but then no one can query records in that 
zone because it's not<BR>> actually delegated unless they point at 
MS-DNS.</FONT><BR></DIV>
<DIV dir=ltr><FONT face=Arial size=2>Is there a reason why you can't 
point all of your internal hosts (AD and non-AD) at your AD's for 
resolution?</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> bind-users-bounces@lists.isc.org on behalf 
of Peter Laws<BR><B>Sent:</B> Thu 3/12/2009 4:51 PM<BR><B>To:</B> 
bind-users@isc.org<BR><B>Subject:</B> Peaceful coexistence with Windows 
domain<BR></FONT><BR></DIV>
<DIV>
<P><FONT size=2>Our environment includes a couple of AD servers.  They 
serve DNS to PCs<BR>using AD (but not all PCs).  They allow DDNS for 
clients and slave the rest<BR>of our environment's zones.  For some reason, 
they *forward* every other<BR>query to us, but never mind that.  Look it up 
your own damn ... well, never<BR>mind.<BR><BR>At any rate, we don't actually 
delegate "their" zone to them.  This causes<BR>problems, as you can 
imagine.<BR><BR>I'm told that the reason we're doing things this way is that we 
don't want<BR>any of those "internal addresses" to be queried by the unwashed 
masses<BR>lurking outside our perimeter.<BR><BR>So my thought was, well, let's 
delegate the zone to the AD servers.  Since<BR>they are already ACLed (or 
whatever MS calls it), no one will be able to<BR>see "their" records off-campus 
but on-campus folks will be able to<BR>(finally) resolv addresses in that zone 
regardless of where they point<BR>(internally) for DNS.<BR><BR>Except that they 
need an MX record for that zone.<BR><BR>So adding the NS record to delegate the 
zone to them properly meant that no<BR>one could see the MX from the outside 
(since the MS-DNS is ACLed).<BR><BR>If I dump the delegation and make an MX 
record in the master, mail will be<BR>OK, but then no one can query records in 
that zone because it's not<BR>actually delegated unless they point at 
MS-DNS.<BR><BR>We thought of slaving that zone on the master, but then we run 
into<BR>security, who doesn't want any of that "internal information" leaked 
out.<BR>No problem, since we're slaving the zone, we'll pop an ACL on it.  
Problem<BR>solved!  Hurray.<BR><BR>Except for that MX record.<BR><BR>Once 
you delegate a zone, you *delegate* the zone.  The MX is 
invisible.<BR><BR><BR>So my requirements are to 1) allow that MX record to be 
seen "outside", 2)<BR>allow any host in our environment to be able to query 
names in any zone<BR>regardless of which system they point at for DNS, and 3) 
not have any<BR>records in that zone be visible "outside" save for that 
MX.<BR><BR>I'm assuming that switching our configuration to use views would 
help, but<BR>we'd like to avoid that, at least for now.<BR><BR>Any quick 
fixes?<BR><BR>I checked, and per the MS-People, MS-DNS cannot put ACLs on 
particular<BR>records.  Neither can BIND, so no surprise 
there.<BR><BR>Which rock do I need to look under?<BR><BR>--<BR>Peter Laws / 
N5UWY<BR>National Weather Center / Network Operations Center<BR>University of 
Oklahoma Information 
Technology<BR>plaws@ou.edu<BR>-----------------------------------------------------------------------<BR>Feedback? 
Contact my director, Craig Cochell, craigc@ou.edu. Thank 
you!<BR>_______________________________________________<BR>bind-users mailing 
list<BR>bind-users@lists.isc.org<BR><A 
href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</A><BR></FONT></P></DIV>

</BODY>
</HTML>