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

[Paul Wouters <[e-mail]>]

On Wed, 21 Sep 2016, Mark Andrews wrote:

> Below is my overview of the sitution.

I like Mark's summary below. I would add:

11) Some software has taken unused delegations causing dilemmas and/or
technical issues (eg .bit or .gnu)

12) Some hardware has taken unused delegations causing  dilemmas and/or
technical issues (eg .box for Fritzbox, .belkin). [note not all vendors
squated on their own brand, see .box]

And my own personal 13) would be:

 	The IETF would like to avoid making any decisions based on
 	specific names or trademarks, unless these pose a risk to
 	the stability and security of the resolving protocols. For
 	DNS specifically, it refers all naming issues to ICANN.

Paul

> 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]
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>