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.

Seems to have been the way the names were devised in RFC2606. Of course,
past performance is no indicator of future results, but I'd still find it
hard to believe that "internal" would end up being created for something
unrelated to the meaning of the word "internal".

> RFC2606 "reserved"
> some TLD labels, even though its just a BCP.

"Just" an RFC, "just" a BCP... hey, it's "just" DNS and "just" IP and
"just" the Internet for that matter.

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

Your point is....? Yeah, right, nothing. They've discovered some purposes
for which defined TLD's could be useful. They reserved them. Their failure
to reserve "internal" as one of them does not lessen the utility of it.
BCP on the Internet is a moving target. There will be things in ten years
that we've not even thought of today.

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

The difference between these being?

Let's look at ".invalid" as an example. Ten years ago, it didn't exist
as something documented in an RFC. In 1996, I started authoring a
little module for USENET news stuff that did basic sanity checking on
addresses, because a customer was having a fantastic problem with news
spammers signing on as "sally@${obscenity}.me.hard", etc. So I wrote a
simple checker that did basic syntax checking on e-mail addresses, and
also prohibited some of those bad words. :-)

Now, a side effect of this was that a great cry arose from customer's
users, who had been used to using invalid e-mail addresses such as "x@x.x"
for posting news, but were also frequently posting as possibly legitimate
domain names. My answer to this was "well, it is probably fine to let
them do this as long as it is not a valid address", and the best technical
way to do that was to create a pseudo-TLD of ".invalid", so that the users
could post as "x@x.x.invalid".

Now, let's review the situation again, and I'll remind you something about
the RFC process along the way.

In 1995, ".invalid" was not a valid or a reserved domain name.

In 1996, my customer began encouraging people to post articles to USENET
news with this pseudo-TLD, rather than other random garbage. This in no
way validated or reserved it, of course.

In 1999, RFC2606 reserved it.

This is hardly unusual in the history of RFC/BCP lifecycles. RFC's
frequently document existing practices, and in this case, I believe the
idea was sound. Apparently some other people agreed.

> This can't be said for your .internal TLD.

That, as I've just pointed out, is mainly a matter of formalization, which
frequently follows actual practice.

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

I'm familiar with 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.

I've seen that, too.

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

All right, then, what would /you/ have done? Bear in mind that the simple
act of just doing the obvious thing represents a lot less work than trying
to lobby ICANN for the reservation of such a name and then putting it
through the RFC process. Given that actually just /doing/ it is
operationally sufficient, and that I don't have a ton of time to go off
tilting at windmills over it, well, the choice was obvious, at least for
us.

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

The only application that cares here is actually packaged and automatically
distributed. There are no desktops, bookmarks, or hyperlinks. There are
gigabytes of records that would list the old name, but I don't deem that a
major operational issue.

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

Yeah, I know. I'm not of that mindset. I still feel that local companies
should register under the US delegated system. :-) (obDisclosure: I wear
the hat of hostmaster@nic.mil.wi.us, etc).

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

Or tough nuts for them. We don't seem to see (m)any requests for some
of these other worthless TLD's anyways. :-)

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

Except that we don't have access to many of the ${hostname} zones, because
typically large ISP's like to manage their own DNS, so placing those
records becomes a nightmare.

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

Damn, man, please include C&C warnings. That's so rude! :-)

I'll bet that, aside from stuff we manage, I've seen less than 1 in 100 do
so. Excellence in engineering isn't the concept at every little network
that is sitting behind a Netgear NAT device. Most frequently the operators
were lucky to get it running as it was.

> That
> stops reverse lookups for these nets going to the root servers and
> getting punted to the AS112 servers.

Well, if there are no operational resolution issues for 10.in-addr.arpa,
then there won't be any for internal either, unless for some reason ICANN
delegates such a strange name out to someone.

Which brings us back to the lessons learned by .invalid.

Actually, I don't really care if it gets accepted as an RFC. It works, it's
obvious, and it's not likely to be a conflict with anything in the future,
and really, even if ICANN does delegate it, it's still not a problem and I'd
probably be questioning the sanity of such a delegation. Heh.

As a final point, I'll mention that I think I had this discussion with
someone like you, almost ten years ago, about .invalid. So it's an old
discussion, and it's not going to change things here. (A real, solid, good
technical reason, on the other hand, ...)

.... JG
--
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.