Peaceful coexistence with Windows domain

[Kevin Darcy]

Peter Laws wrote:
> 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?
>
You can't really have it both ways, either the zone is visible or it 
isn't. The MX record is at the very top of the zone -- what is often 
called the "apex" -- so it's not like you can delegate it and put an ACL 
on the delegated zone.

It seems a little inconsistent to me that your Security folks don't mind 
the MX record being exposed but they're paranoid about the zone's other 
"internal" stuff leaking out.

I don't see any way to to meet the requirements you've been given, as 
you've described them. There's nothing really unusual about having 
separate internal-versus-external versions of your namespace, and the 
delegation structure doesn't need to be the same for both. So why not 
just stick with an undelegated AD zone in the external version? You can 
still delegate it in the internal version, if it makes you feel better.

- Kevin