Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

[Mark Andrews <[e-mail]>]

I tend to agree that it may be impossible to give precise rules
for special names handling.  Below is my overview of the sitution.
6 is my opinion.

1) Today domain names are resolved with a number of protocols (e.g.
DNS, MDNS, TOR, NIS).

2) Some names are meant to be globally visible (*.onion) and some are
ment to be only be locally visible (*.local, *.10.in-addr.arpa) and
for some only the delegated authority knows the desired visibility
level.

3) Sometimes the contents of the name signals which protocol should be
used to resolve the name.  e.g. *.local -> mdns, *.onion -> tor.

4) Rules are sometimes needed to inform the resolution software about
which protocol to use.

5) Rules are sometimes need to handle lookups occuring in the wrong
protocol or the wrong place. e.g. *.onion in the DNS, AS112 servers
to 10.in-addr.arpa and locally served local zones, deliberate
breaking of DNSSEC chains of trust.

6) Names should only be used to identify stuff when you have been
delegated them either explicitly or implicitly (e.g. RFC 1918
implicitly delegates 10.in-addr.arpa to anyone using RFC 1918 space).

7) The default resolution mechanism is the DNS.  There are standard
proceedures for delegating names in the DNS.

8) Sometimes it is necessary to perform non standard delegations that
don't follow the normal proceedures as the requirements of the
delegation don't match the normal state of affairs.  The delegation
of .onion for the use of TOR is a example of such a delegation as
well as the delegation of .local for MDNS.

9) Such delegations by their very nature need to be handled on a case-
by-case basis which needs to be co-ordinated with the delegating
authority that normally handles that part of the namespace.  They
are exceptions to the normal rules.

10) Undelegated use of a name complicates the decision to delegate a
name either using conventional mechanisms or using exception
mechanisms.  So to does concurrent requests for a name especially
a TLD. So to does trade mark issues.


In message <[e-mail]>, Warren Kumari writes:
> On Tue, Sep 20, 2016 at 9:33 AM, Stephane Bortzmeyer <[e-mail]> wrote:
> > On Fri, Sep 16, 2016 at 05:53:53PM -0400,
> >  Warren Kumari <[e-mail]> wrote
> >  a message of 31 lines which said:
> >
> >> However, if there is not sufficient review and feedback for the
> >> chairs to be able to select between them (or some other clear
> >> outcome), we will be stuck... and then we will continue to talk
> >> about this topic ad nauseam[0].
> >
> > Or we could decide that the problem is not solvable in the current
> > context and tell that to the IESG.
> 
> We could -- it is entirely possible that this is not a solvable
> problem -- however, before we can make that determination, and even
> more importantly, before we can clearly communicate that to the rest
> of the IETF / IESG / <etc> we need to agree on what the *problem*
> actually is.
> 
> This is what draft-tldr-sutld-ps is trying to do -- clearly document
> the problems with special use names, not just the problems with
> RFC6761.
> 
> Once we've documented the problem we can then discuss *mitigations* (I
> suspect not solutions), and if there is anything useful we can
> actually do...
> 
> 
> W
> 
> > Some things are simply not
> > possible. And I'm still not convinced there is a problem to solve
> > (unless the real issue is "how to prevent the registration of .gnu and
> > .bit?")
> >
> > The rest of this email is about
> > draft-adpkja-dnsop-special-names-problem-06. Executive summary: no, no
> > and no.
> >
> > Problems
> > ********
> >
> > Despite many remarks on this list and in IETF meetings, the draft
> > continues to use disparaging terms like (section 1) "squatting".
> >
> > Several remarks in the draft are dishonest because they could be
> > applied as well to many IETF technologies. It really seems the authors
> > felt the draft was too short and decided to pile in anything they
> > could find against 6761. For instance, section 3 says:
> >
> >> [RFC6761] does not mention if the protocol using the reserved name
> >> should be published as an RFC document.
> >
> > So what? It was never a problem at IETF to rely on protocols which are
> > not in a RFC. (See for instance the "Specification Required" policy in
> > RFC 5226.)
> >
> > Another instance of the same problem, section 4 says:
> >
> >> c.  Reserving a string in [RFC6761] does not guarantee queries will
> >> not leak in the DNS.
> >
> > Requiring this is outrageous: there is no way to prevent
> > implementations to do stupid things. RFC 1918 does not "guarantee
> > packets will not leak [in the public Internet]" and nobody is going to
> > criticize RFC 1918 for that. (Not to mention the DNS leaks of
> > rfc1918-domains.arpa.)
> >
> > Section 5:
> >
> >> This leads to concerns about liability risks incurred by adding a
> >> particular string to the [RFC6761] registry.
> >
> > There is no way to guard against any issue that a US lawyer may
> > raise. Until now, no owner of the Local or Onion trademarks
> > complained, or threatened to sue.
> >
> > Errors
> > ******
> >
> > Section 1 :
> >
> >> the GNU Name System (GNS) system is using block chains to build a
> >> decentralized name system
> >
> > GNS does not use any blockchain. (Confusion with Namecoin?)
> >
> > Little details
> > **************
> >
> > Abstract :
> >
> >> RFC 6761 introduced a framework by which a particular domain name
> >> could be acknowledged as being special.
> >
> > Actually, suffix, not domain name (RFC 6761, section 4).
> >
> > Section 1 :
> >
> >> An algorithmic solution frequently chosen by application developers
> >> consists simply in using a special tag padded at the end of a name
> >
> > Why calling it "tag", instead of "label" (or "suffix" if there are
> > several labels)?
> >
> 
> 
> 
> -- 
> 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
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]