What Paul mentions below raises the specter of name collisions - the activation of a name resulting in undermining a errant system which, until the activation, wasn’t all that bothered by the name being inactive. Search lists have been one root cause suggested and sometimes even observed as contributing to this problem.
The issue here is that there are strings that humans use for identification
and there is the DNS. There’s an overlap when DNS names are transliterated
into printable format - what I mean is that “example.com.” isn’t what the
DNS passes over port 53, it passes
“0x07’e’’x’’a’’m’’p’’l’’e’0x03’c’’o’’m’0x00”. But we read and write that
as example.com.
There’s a barbershop near the ICANN offices (ironically enough) that has
this on their store front: minibar.ber.shop. That’s not a domain name, it
is the name of a store. They did also have “www.minibarbershop.com” on the
banner announcing they’d open in June 2014. (They advertise beer and
haircuts - I just hope the person with sharp objects isn’t drinking as they
snip. And I’m not sure how you drink beer and keep your head still. But I
digress.)
I see the problem as creating a way to use dotted names (that look like
transliterated domain names) that will never resolve in the DNS. (I think
that’s pretty obvious.) To do this, what’s needed is a space in the DNS
that will just not be used. Here “ALT” is proposed.
I am supposed to be working on (as in, I’d be doing it now if I weren’t
responding to email) a draft to propose that the strings corresponding to
the ISO 3166("mumble-mumble" as Warren says) two letter codes for counties
and regions what are categorized as “user assigned” be set aside as TLDs
that won’t ever happen. (For example - “xx”) I’m just throwing this out
here as an idea - please respond privately to me until I can get a coherent
draft together on this. (In the mean time, Wikipedia has a short
description of these codes at
http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#User-assigned_code_elements.
)
What’s promising about reserving the user assigned two-letter codes is that
there is already a $policy (perhaps it’s folklore) that when it comes to the
two letter codes, IANA heeds the advice of the ISO 3166 documents. Except
for dotUK (and that is noted in Wikipedia’s article).
(An aside, if anyone knows of a formal statement of such a policy, I’d
appreciate it if you can send that to me privately for the draft. I’ve
heard it said many times over the years, but I don’t know that it was ever
formalized. Perhaps in some old RFC…)
The only way for all this is to build a convention, because there’s no
protocol solution, for classifying dotted string formatted identifiers as
DNS transliterations or, well, something else. The only way for the DNS to
not be part of the problem is to burn in the convention so that it doesn’t
undermine errant applications - and by errant here I mean applications using
a legitimate identifier space assuming that it’s part of the DNS space.
On 2/13/15, 0:45, "Paul Vixie" <p...@redbarn.org> wrote:
>
>
>> David Conrad <mailto:d...@virtualized.org>
>> Thursday, February 12, 2015 5:38 PM
>> George,
>>
>>> The politics response is really simple: "this idea is doomed." -I wish I
>>> felt otherwise, but I think given the context of the debate over ICANN, who
>>> 'owns' names, $180,000 application fees, IAB directions to IANA, NTIA role,
>>> this is mired. I don't want to be a prophet of doom, but this is my honest
>>> perspecive.
>>
>> As with most "really simple" answers, the reality is a bit more complicated.
>> My impression of this draft is that it creates a space that would avoid some
>> of the risks associated with RFC 6761. Politically, I suspect this is
>> desirable, even to all the parties you mention. As for the fee, ICANN already
>> defers to the IETF in protocol-related matters, so I don't see why a new gTLD
>> fee would be applicable. With my ICANN hat on, I'll look into this and
>> report what I hear back.
>
> can we sit back and ponder what it will mean if .ALT becomes an implicit extra
> search list for many end users, and then xyzzy.alt is created, and later,
> .xyzzy is created. i expect this eventuality to spur considerable interest
> from icann, perhaps coming in the form of "since we can't control what the
> ietf does with implicit search list behaviour, we're skittish about allowing
> something like .ALT to come into existence that would, when combined with
> implicit search lists, lead to complete and utter chaos."
>
> this is not in other words simply a protocol-related matter.
>
> --
> Paul Vixie
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
