ICANN opens up Pandora's Box of new TLDs
tme at multicasttech.com
Fri Jun 27 16:48:50 UTC 2008
On Jun 27, 2008, at 12:21 PM, Lou Katz wrote:
> On Fri, Jun 27, 2008 at 12:13:10PM -0400, Marshall Eubanks wrote:
>>>> Well, I guess this shoots in the foot Microsoft's name server best
>>>> practices of setting up your AD domain as foo.LOCAL, using the
>>>> that .LOCAL is safe because it cannot be resolved by the root name
>>>> Who wants to be the first to try to register *.local?
>>>>> They should have been following RFC 2606.
>>> Thinking about it a little more, what about the common use of
>>> 'localhost.localdomain' for 127.0.0.1 in most versions of *nix? I
>>> just imagine the chaos that registering a *.localdomain TLD will
>> .localhost is already reserved through RFC 2606, so this should not
>> a problem. To quote :
>> The ".localhost" TLD has traditionally been statically defined in
>> DNS implementations as having an A record pointing to the loop back
>> address and is reserved for such use. Any other use would conflict
>> with widely deployed code which assumes this use.
>>> Methinks it is time to update RFC2606 to reflect common practices
>>> the new ICANN policies take effect.
>> If you can think of a list, it probably would...
> Having had the need to construct a few TLDs for internal use, I hope
> that some
> new RFC will address this and reserve some
> (e.g. .internal, .internal# (where # is
> any fully numeric string), .local)? I really don't care what they
> are called,
> but I do need more than one.
There are 4 already,
.test .example .invalid .localhost
. I suspect that .local should also be reserved, which would make 5.
It seems that .internal# should just be blocked, not reserved. Before,
the feeling was that
the best blockage was a reservation, but as I read the ICANN
presentation, if .internal
was reserved, .internal# could be blocked too without an explicit
> Helping to interpret the lives of the animals.
More information about the NANOG