different internal and external views of a zone

[Merton Campbell Crockett]

On 14 May 2006, at 08:31 , Karl Auer wrote:

> How do others deal with this problem?
>
> Lets say a DHCP client wants to register foo.domain.com with a private
> (RFC1918) address. The server can register the mapping on behalf of  
> the
> client, or the client can do the registration itself, but one way or
> another the forward mapping ends up in the internal view of domain.com
> (we'll leave the reverse mapping out of this for the moment).


I use the ISC DHCP Server.  It performs the update of both the  
reverse and forward zone files and passes the option to the DHCP  
Client instructing it not to update DNS.  The instruction is not  
always observed.  As a result, BIND is configured to only accept  
updates from the ISC DHCP Server.


> Internal DNS clients can now look up foo.domain.com and get the  
> right IP
> address. External DNS clients cannot resolve foo.domain.com,  
> because it
> is not in the external view. So far so good.
>
> Now along comes another DHCP client, and wants to register
> bar.domain.com, with a public address. So we end up with another  
> mapping
> in the internal view of domain.com, because whether the DHCP server  
> does
> it or the DHCP client, there is, from the updater's point of view,  
> only
> one place to update domain.com.


I don't allow any dynamic updates to zone information that will be  
exposed to the public Internet.  All public addresses have pre- 
defined, nondescript names that bears no relationship to the name of  
the system currently using the IP address.  The name to use is passed  
back to the DHCP Client and is, typically, ignored by Windows-based  
systems.


> So now we have problem number 1: The name bar.domain.com is not  
> visible
> to external DNS clients, but it needs to be.
>
> Obvious answer: Secondary the internal view of domain.com out to the
> external view, so that external DNS users can resolve bar.domain.com.
>  But that brings us to problem number 2: If we do this, we will be
> exposing the private address to external DNS users, because they can
> then resolve foo.domain.com as well.
>
> In short, domain.com needs to be in both the internal and the external
> views, but needs to be different in each view.
>
> Manual updates can of course be made in as many views as we want;  
> it is
> the dynamic updates that seem problematical.
>
> Here's the requirement:
>    - internal DNS clients can resolve names with private OR
>      public addresses
>    - external DNS clients can resolve only names with public addresses
>    - some DHCP clients will have private addresses
>    - some DHCP clients will have public addresses


My approach satisfies the above requirements.

In my environment, there are external name servers and internal name  
servers.  The external name servers present a static, consistent view  
of the forward and reverse zone data to the Internet.  Internally,  
the ISC DHCP Server will perform dynamic updates to both private and  
public IP address blocks.  So far, I haven't discovered any systems  
on the Internet that care whether the fully-qualified domain name  
used internally matches the name associated with the IP address seen  
on the Internet or not.  The only issue of any importance is that the  
reverse and forward domain information exist and that it is consistent.


> The only solution I can see is to force those clients on private
> networks to use particular domains that are for internal consumption
> only. This restriction has quite a few downsides, though.
>
> Any other ideas?


Were there a need for the external and internal zone information to  
match, I would configure the ISC DHCP Server to perform dynamic  
updates to both the internal and the external name servers.


Merton Campbell Crockett
m.c.crockett at adelphia.net