Re: Authoritative Server - Referrals to root

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