Sorry if this is just a reprise of a previous discussion, I'm new to
this list.
I think the concept of an extensible registry for special use domain
names is complete madness, and the registry should document only
existing special cases, and not permit any more registrations. .onion
should be rescinded.
IMO It is insane to allow the addition of a name to the special use
names registry to make every DNS agent on the planet no longer
compliant.
RFC6761 doesn't seem to really contemplate the logistics of modifying
all DNS resolvers and servers on the planet. It's a sisyphean task.
Our product includes a DNS resolver. Even if we did add support for
.onion, we can't (and wouldn't even if we could) _force_ our customers
to upgrade. So the only thing you can count on is that there will
remain for considerable time a considerable deployment of resolvers who
ignore any new special use names. I'm sure you all know that, but it
seems foolhardy to negotiate sensitive information over .onion
resolution when that is highly likely to leak.
Surely .onion could have been handled in the application, without
pushing it down to the resolution layer.
Adrien de Croy
------ Original Message ------
From: "George Michaelson" <g...@algebras.org>
To: "Suzanne Woolf" <suzworldw...@gmail.com>
Cc: "dnsop WG" <dnsop@ietf.org>; "David Conrad" <d...@virtualized.org>
Sent: 30/03/2016 1:19:49 p.m.
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
Make the application for .alt actually ask for xn--59g and I'd be
there.
or even xn--3ve9dwb1a
The application demands .alt? It has the same problems as any other.
Its sole purpose should be uniqueness, and choosing a string which has
semantic meaning for a large community is confronting the issue up
front: It should a symbol-string which has less chance of being asked
for as a name in social contexts, has more chance of being
justifyable.
-G
On Wed, Mar 30, 2016 at 9:23 AM, Suzanne Woolf <suzworldw...@gmail.com>
wrote:
David,
On Mar 28, 2016, at 11:47 PM, David Conrad <d...@virtualized.org>
wrote:
FAQ #22 says CORP, HOME, and MAIL have been deferred indefinitely,
Yep. The report on name collisions that ICANN commissioned had the
following recommendation (recommendation #1 as a matter of fact, see
https://www.icann.org/en/system/files/files/name-collision-mitigation-final-28oct15-en.pdf,
top of page 5):
"The TLDs .corp, .home, and .mail be referred to the Internet
Engineering Task Force (IETF) for potential RFC 1918-like
protection/treatment."
Unfortunately, the IETF decided agains this treatment, so those
strings remain "deferred indefinitely."
I suspect it would be helpful to the draft authors and the WG to
provide a public reference for the implied statement here, because it
could be important to mapping the current relationship among different
uses of the namespace.
You seem to be saying that the fact the IETF hasn’t added those
strings to the special use names registry, per the recommendation of a
third party consultant hired by ICANN, is somehow part of why they’re
“deferred indefinitely” instead of having some other status, but it’s
not completely clear to me what relationship there is among those
things.
I’ve never been able to find any reference to the IETF special use
names registry, or any discussion of its impact on ICANN policy, in
the Applicant Guidebook for the previous gTLD round, or indeed
anywhere else. I also haven’t seen a liaison or other open
communication from ICANN containing an opinion about having the IETF
reserve the names you mentioned.
I’ve always seen people assume that an entry in the special use names
registry means that ICANN won’t delegate the same string in the DNS
root. But given other discussion in this thread, where the claim is
being made that any IETF action regarding strings for “special use” is
subject to socio-economic pressures just as ICANN actions would be, I
don’t see the basis of the assumption.
Doubtless I’m missing something though….is there a citation we can
ask the draft authors to incorporate in the future?
thanks,
Suzanne
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
