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.


1) Today domain names are resolved with a number of protocols (e.g.

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

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 
<cahw9_ij-9mmsu30fyetjd7y7bpdh3bfjixok8de_uynuf65...@mail.gmail.com>, Warren 
Kumari writes:
On Tue, Sep 20, 2016 at 9:33 AM, Stephane Bortzmeyer <bortzme...@nic.fr> wrote:
On Fri, Sep 16, 2016 at 05:53:53PM -0400,
 Warren Kumari <war...@kumari.net> 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

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...


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

The rest of this email is about
draft-adpkja-dnsop-special-names-problem-06. Executive summary: no, no
and no.


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

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.


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.

DNSOP mailing list
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: ma...@isc.org

DNSOP mailing list

DNSOP mailing list

Reply via email to