different internal and external views of a zone

[Karl Auer]

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).

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.

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

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?

Regards, K.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)                   +61-2-64957160 (w/h)
http://www.biplane.com.au/~kauer/                  +61-428-957160 (mob)