--On Wednesday, July 15, 2015 12:40 -0700 Ted Hardie
<ted(_dot_)ietf(_at_)gmail(_dot_)com> wrote:
suppose we decided that all new special names
associated with protocols and intended for special resolution
mechanisms be allocated (and placeholders delegated if needed)
in a separate DNS CLASS, say "SN" for "Special Name". Zero
impact on the ICANN/IANA root from queries gone bad, no
conflict with names ICANN allocates even if the labels are
...
I went through the same experiment, and I even considered
how to adapt a long-ago dropped proposal for cross-class
pointers
<https://www.ietf.org/archive/id/draft-hardie-out-rr-00.txt>
to adapt Ted Lemon's NSEC method (essentially, using DNSSEC
to secure the cross-class pointer record instead of the
NXDOMAIN). I think it could work, but as you say, there are a
lot of potential issues with making this deployable. There are
a *lot* of things (and organizations) that presume IN is the
only class, and it's not clear that they would go along. If
CABrowser Forum did not, for example, much of the reason the
.onion folks want a DNS special name would not work.
Yep. Glad you are ahead of me and that our exploration went
down approximately the same path.
Keeping in mind that I've far more concerned about where we go
next and what the boundaries and criteria are than about any one
name, part of my thought was to be able to say to the next
applicant who comes along
"We can give you, the applicant, four options, two easy and two
harder:
(i) CLASS=IN, but a subdomain below something (I'll
leave whether the current 'ALT.' proposal is the right
'something', or whether even something analogous to it
should be 'ALT.ARPA.', for a separate discussion).
(ii) CLASS=SP, top-level domain.
(iii) CLASS=IN and a TLD, but with _really_ high
threshold for justifying that choice.
(iv) Go do whatever ICANN specifies for a TLD that you
don't intend to resolve in the normal/public DNS. To
the best of my knowledge, there is no such procedure
today. ICANN could create one, in which case how it
works is not an IETF problem. Or they could decline to
do so, in which case this option is a no-op. That isn't
an IETF problem either."
For options (i) or (ii) the IETF probably wouldn't want quite
FCFS, but an Expert Review/ Sanity Check would probably be
sufficient. Either one requires that people either come to us
when the protocol is designed so an appropriate DNS setup can be
chosen or negotiated. If things are already deployed, the
question would become whether it is easier to upgrade relevant
applications or to be pushed over into one of the other
options... but that is not an IETF problem.
For (iii), I don't know that we always say "no", but, if only
because such reservations either interact with ICANN gTLD
application procedures or create the kinds of operational and/or
security risks that several people have identified, we would
presumably need to understand why some other option wasn't
appropriate, what was proposed to mitigate the risks, some
review or policy model that was hostile to squatting strategies,
and lots of deployment (although presumably not up to the level
of "localhost."
Again, I don't know whether that model should be applied to
"onion." or not. Part of the answer obviously depends on
whether there is a "good and virtuous cause" exemption because
concerns about squatting, etc., obviously arise even though any
reasonable minimum deployment criteria are almost certainly met.
I think part of the answer to those questions require that the
IETF explore how far it is willing to go in support of
sociopolitical and/or privacy concerns and where the stopping
points are in that direction. However, if the model did apply
to "onion.", presumably part of the answer would be to tell the
applicants/registrants that the job of convincing the CABrowser
Forum or other implementers to do whatever is needed is their
problem, not ours.
best,
john