Authoritative Server - Referrals to root

[Jim Reid]

>> If there's something I've overlooked, please tell us.
>
> 1) /IF/ a TLD named "internal" were created, it seems likely and 
> obvious
>    that there's a good chance it would be created for purposes 
> apparently
>    relating to the meaning of the word, and hence would likely be the
>    equivalent of 10-net space.

First of all, that assumption may not be the justification for the 
creation of that TLD if it ever does get created. RFC2606 "reserved" 
some TLD labels, even though its just a BCP. .internal wasn't one of 
them. BTW that RFC says the labels are for "private testing of existing 
DNS related code, examples in documentation, DNS related 
experimentation, invalid DNS names, or other similar uses": nothing 
about internal naming schemes.

Secondly, you're confusing a bogus, internal-use-only TLD, with a valid 
domain name. Creating your own private copy of 10.in-addr.arpa (or any 
other reverse zone for RFC1918 nets) is mostly harmless.  On the 
internet, 10.in-addr.arpa already exists and has a defined purpose. 
This can't be said for your .internal TLD. In fact, private copies of 
the reverse zones for RFC1918 nets is a Very Good Thing. It takes a lot 
of bogus traffic away from the root servers. [Check out the AS112 
project.] There is of course a whole world of pain whenever two or more 
of these nets are merged: say when the intranets of two organisations 
are joined together after a merger or acquisition.

Note that I'm not saying having a TLD like .internal for private 
purposes is a Bad Thing. It's just that the name of that TLD needs to 
be agreed and documented. The name shouldn't just be plucked out of 
thin air. If a domain name is to be used for internal purposes, its 
name should be one that's been expressly set aside for that purpose. ie 
Those using that name can be certain it's not going to appear on the 
public internet. That holds irrespective of whether the chosen 
internal-only domain is a TLD or not.

> 2) /IF/ a TLD named "internal" were created which was not actually 
> intended
>    for internal use, but, perhaps, was meant for domain names for 
> doctors
>    of internal medicine, or some other lameness, well, really, it's 
> /not/
>    that hard to do s/internal/foo/ in your zones tree.

That would be the easy bit. You then have to go through every desktop, 
bookmark, hyperlink and application in your net to make sure they now 
use your bogus foo TLD instead of your bogus internal TLD. Then you get 
to repeat that when ICANN  gets around to creating .foo. :-)

> It seems highly unlikely to happen.

When it comes to ICANN and TLDs, anything is possible. :-) There are 
some voices at ICANN who advocate there should be thousands of TLDs and 
market forces can decide which ones survive and which ones don't. If 
those voices get elected or become the orthodox viewpoint....

> 3) There's generally plenty of warning of up and coming new TLD's, so
>    neither 1 nor 2 are currently an issue, and by the time it would 
> be, it
>    still isn't because we'd have done something about it.

In other words, tough nuts for you. As I said already.

> We, however, have lots of boxes out at customer sites, and since our
> customers are allowed to renumber and move equipment on their networks 
> as
> dictated by their own engineering needs, the complexity of such a 
> solution
> started to get a bit much.  Our particular deployment design involves
> having a private 10-net address for each server (simply the public IP
> address/netmask, with the first octet changed to 10) for intraserver
> transfer, management, and other various purposes. This particular 
> solution
> allows us to call the external interface "${hostname}", and the 
> internal
> interface "${hostname}.internal", which has a nice symmetry, and can be
> automatically derived.

So could "internal.${hostname}".

> I guess the interesting question is how many operational resolution 
> issues
> are there at sites that have installed RFC1918 zones as local masters?

There shouldn't be any. If a net is using RFC1918 addressing it really 
must run reverse DNS for the corresponding in-addr.arpa zones. That 
stops reverse lookups for these nets going to the root servers and 
getting punted to the AS112 servers.