Re: [DNSOP] followup and proposed actions: RFC 6761 interim and next steps

[Warren Kumari <[e-mail]>]

On Tue, May 19, 2015 at 6:18 PM, Suzanne Woolf <[e-mail]> wrote:
> Dear Colleagues,
>
>
> First, thanks for extensive and thoughtful discussion on the list and in our
> interim meeting last week on the way forward for the internet-drafts
> requesting special use names registry entries under RFC 6761.
>
>
> This message is fairly long, and contains some impressions of where we are,
> a couple of actions we expect to take in the next few days, and some
> questions we’d like to pursue going forward. Please read all of it if you’re
> interested in the overall topic; we have significant challenges of both
> process and substance to navigate.
>
> It's clear that applying RFC 6761 is challenging, and one of the outcomes
> we'd like to see from the current discussion is serious consideration of
> whether we need to update it with a new document suggesting additional
> guidelines or considerations.
>
>
> First, some initial impressions:
>
>
>
> .ONION (draft-appelbaum-dnsop-onion-tld-01):
>
> * There’s significant support for the .onion request, in terms of the draft
> itself and what the TOR project is trying to accomplish by supporting the
> protocol and making the request.
>
>
> * There are some reservations about .onion. We heard concerns that we might
> be setting a precedent for arbitrary appropriation of namespace; that the
> protocol may not be thoroughly documented, and that we’re not clear on how
> high the bar should be for a special use name.
>
>
>
> .ALT (draft-wkumari-dnsop-alt-tld-06):
>
>
> * There’s significant support for .alt as a possible alternative namespace
> for implementers who want namespace they’re certain won’t resolve in the
> global DNS, but are willing to be flexible on what namespace they use.
>
>
> * There are operational questions about .alt that would have to be resolved
> in further development of the draft, such as whether to assume “leaked”
> queries would be sunk to AS112.

We updated the draft yesterday, it currently says:
"The ALT TLD is delegated to "new style" AS112 servers, and so
recursive and stub resolvers
   will get NXDOMAIN for all queries.

   1.  Iterative resolvers SHOULD follow the advice in [RFC6303],
       Section 3.

   2.  The ALT TLD is delegated to "new style" AS112 nameservers
       ([I-D.ietf-dnsop-as112-dname] ), which will return NXDOMAIN for
       all queries.

   These rules are intended to limit how far unintentional queries (i.e.
   those not intended for the global DNS) flow."

(this text is actually out of date, I-D.ietf-dnsop-as112-dname is now
RFC 7535 (fixed in edit buffer / github ))

It also goes on to say (in the IANA Considerations section):
"In addition, the "Locally Served DNS Zones" ([RFC6303]) registry
should be updated to reference this document."

The plan is that queries that leak into the DNS should be dropped as
soon as possible, and should not add significantly to the root junk
queries[0].
Once added to Locally Served DNS Zones (and recursives have been
updated) they should be dropped there, any which happen to still slip
through should be punted to AS112, and dropped there (and, if qname
minimization / resimprove happens, .alt itself would be cached by
recursives that ignore locally served zones).

>
>
> * There was some concern that implementers who want single-label or “TLD”
> namespaces would not accept .alt as a possible alternative

Yup. That's entirely possible / likely. But, after .alt exists, people
who want to be a: responsible or b: experiment actually have a good
alternative. Some implementors will no doubt simply choose a single
label (.foo) and use that -- but, when they later come ask for it to
be added to SUN, we / the IESG can push back and say that there was an
alternative...

>
> * There was some question as to what would be gained by .alt that we don’t
> already have in .invalid, which is also already reserved

.invalid is reserved, but doesn't get the special handling that we
would be requesting for .alt (perhaps it should though; I smell
another draft in the making :-)). Strings also have human meaning - if
I want to create a resolution system using distributed hash tables  /
prefix tree that uses a concatenation of the entered name with a
"selector" to create multiple parallel namespaces I *may* be willing
to use names for the form <something>.decentralized.alt... but I'd be
much less likely to be willing to use
<something>.decentralized.invalid.
For better or worse, labels *do* have meaning (as demonstrated by
ICANN auction proceeds topping $61,000,000USD)

>
>
>
> HOME/CORP/MAIL (draft-chapin-additional-reserved-tlds-02):
>
> * This is the most controversial of the RFC 6761 drafts and the one most
> driven by policy concerns
>
>
> * The draft assumes that these names are commonly being used in local DNS
> contexts and often “leak” into the public internet. Specific uses are not
> documented.
>
>
> * The most commonly used justification for this reservation was the risk of
> name collision if ICANN delegates these names in the production root zone.
>
>
> * Since ICANN has said that they’re not currently planning to delegate these
> names, the justification further seems to assume that ICANN’s assurance of
> this is not a sound basis for believing that risk is contained
>
>
> * There were questions about how to quantify name collision risk, or
> otherwise set a threshold for what operational characteristics of the
> appearance of a given name in the public internet would justify a conclusion
> that it should be “protected” by the IETF from delegation in the production
> root zone
>
>
>
> ADDITIONAL NOTES:
>
> There was some discussion of other drafts as well. In particular, there was
> some willingness to review the requests currently contained in
> draft-grothoff-iesg-special-use-p2p-names-04 if presented in separate
> drafts, as that would make it easier for the WG to properly consider those
> requests.
>
>
> MOVING FORWARD:
>
> We expect to take the following steps:
>
> 1. A call for adoption on the WG list of draft-appelbaum-dnsop-onion-tld-01.
> Given that there's clear support for it and a timeliness concern, we'd like
> to see if we can get to a consensus to move forward with it.
>
> 2. A call for adoption on the WG list of draft-wkumari-dnsop-alt-tld-06, and
> further discussion on the list to the operational questions mentioned above.
> We're all aware this isn't a complete solution to the perceived demand for
> special use names; can it be used to make the situation notably better?

I believe it can -- it provides people who want to create alternate
namespaces a legitimate way to do so.

This document was initiated in Feb 2014, and is now at revision -06.
During its life it has received a fair bit of discussion, including
being presented / discussed at:

IETF-89  - Berlin -
http://www.ietf.org/proceedings/89/slides/slides-89-dnsop-15.pdf
IETF-91 - Dallas -
http://www.ietf.org/proceedings/92/slides/slides-92-dnsop-5.pdf
The "special use names" interim: (no slides)
https://www.ietf.org/mail-archive/web/dnsop/current/msg14238.html
and around 75 or 80 emails.

I have attempted to capture and incorporate all of the comments
received. The most recent set of changes was:
a: make it clearer that this is for *new* pseudo-TLDs. Existing ones
may choose to move under .alt if they wish (it's open, there is
nothing we could do to stop them if we wanted!), but are not expected
to.

b: to remove the request that IANA create and run a registry where
people can (optionally) register their use of the string. Various
people (myself included) were concerned that this looks too much like
a "real" TLD then, with the IETF as the registry and registrar. This
would open the whole can of worms, with trademark and similar issues.

As always, if this is adopted by the WG (and the chairs select us to
continue editing), we will incorporate whatever WG consensus is.

Thank you,
W


Condensed change log below:

 From -05 to -06
   o  Incorporated comments from a number of people, including a number
      of suggestion heard at the IETF meeting in Dallas, and the DNSOP
      Interim meeting in May, 2015.
   o  Removed the "Let's have an (optional) IANA registry for people to
      (opportinistically) register their string, if they want that
      option" stuff.  It was, um, optional....

   From -04 to -05
   o  Went through and made sure that I'd captured the feedback
      received.
   o  Comments from Ed Lewis.
   o  Filled in the "Domain Name Reservation Considerations" section of
      RFC6761.
   o  Removed examples from .Onion.

   From -03 to -04
   o  Incorporated some comments from Paul Hoffman

   From -02 to -03
   o  After discussions with chairs, made this much more generic (not
      purely non-DNS), and some cleanup.

   From -01 to -02
   o  Removed some fluffy wording, tightened up the language some.

   From -00 to -01.
   o  Fixed the abstract.
   o  Recommended that folk root their non-DNS namespace under a DNS
      namespace that they control (Joe Abley)





>
> 3. Further discussion on the WG list of
> draft-chapin-additional-reserved-tlds-02. Given that we don't currently see
> consensus to move forward with it, and the support for it seems widely
> fragmented among technical and policy-based reasoning, we'd particularly
> like to see any NEW input on:
>
> * What is the specific operational impact being sought by adding these names
> to the special use names registry? Is the goal to have an impact on anyone
> besides ICANN?
> * Some of our discussion so far has suggested that there's a difference
> between basing a decision about a special use names delegation on intended
> use in a new protocol, such as .onion, and basing such a decision on unknown
> and unspecified use, perhaps particularly within the DNS. In the interests
> of evaluating future such requests that might also not be based on a
> specific protocol use, is there a bar we can set besides the discussion in
> the current draft of inferred name collision risk?
>
> 4. It's been pointed out that the maintenance of the special use names
> registry is complicated by the fact that people used to be able to assume
> the root zone was relatively stable, and this assumption has become less
> defensible. (ICANN is not currently accepting new applications for TLDs, and
> has no announced schedule for opening an application window again, but has
> said they plan a future application round.) Is there something that the IETF
> should be doing to help DNS implementers and operators handle this change in
> the environment?
>
>
> thanks,
> Suzanne and Tim
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf