Subject: Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt

From: Ted Lemon <[email-masked]>
Date: Sun, 2 Feb 2014 09:42:40 -0500

On Jan 29, 2014, at 7:45 PM, Mark Andrews <[email-masked]> wrote:
> The squatted tld's used by software .onion, .bit etc could be
> migrated to a new namespaces.  Just issue new software that looks
> / recognises in the new namespace first then in the old one for X
> years.  After X years stop looking in / recognising the old namespace.
> Set X to about 10 years and there will be very little old code left
> when you turn off support for the namespace.  Set and compile in
> the drop dead date.

Ten years is a long time, and even if the schedule you recommend is practical, the conflict will still cause problems in the short term, which is what actually matters.   The IETF could choose to simply punt on this and let ICANN deal with it however they want, but there's some degree of consensus that we ought to document these issues, and that's why this draft is up for consideration.

The point is not to say "squatting on TLDs is ok" or "special-use TLDs for these uses is the right architecture," but rather to say "special-use TLDs for these uses exist; here is what they are; here is where to go to learn more about them."

In my mind, the criteria for deciding whether to document them are (a) whether there is some serious effort out there somewhere to use them _on the internet_, (b) that someone proposes to document the use in the IETF under RFC 6761, and (c) that we think there is sufficient interest in the usage being documented that it's reasonable to think that, were the TLD in question to be assigned in the DNS, significant problems would ensue.

(c) is a judgment call, (b) is a prerequisite for RFC 6761 to apply (the IETF does not have change control for the namespace, but is an appropriate venue for documenting uses of it), and (a) is a requirement because if (a) doesn't apply, it's simply not the IETF's problem.

It's certainly reasonable to say that we ought to make architectural recommendations to proponents of these special-use TLDs, but we can't actually stop them from using them.   It's somewhat analogous to the situation with TXT records.

So if we punt on this and refuse to document these special use TLDs under 6761, it doesn't actually solve the problem, or make anything better.

And although several heavy hitters in the DNS working groups do apparently feel strongly that special use TLDs are a bad architectural choice, there is no consensus in the IETF for this position (yes, I am saying that with my AD hat on).

The IESG would prefer to see these proposals worked on by DNSOP, because that will likely improve the documents.   Part of that improvement might be some recommendation for sunsetting, although I am skeptical that that will gain consensus.

But we've been down the "this is a bad idea, let's not document it" path before, and it leads to worse outcomes than documenting it.   So I'd really love it if we could see some discussion of how to make the document better, rather than simple rejection of the proposal.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 3 Feb 2014 16:19:59 +0100

On Thu, Jan 30, 2014 at 11:45:30AM +1100,
 Mark Andrews <[email-masked]> wrote 
 a message of 74 lines which said:

> migrated to a new namespaces.

:-)

"squatted" is not a bad word here. In the physical world, squatters
are often people who do not have the money to rent a home, because
some rich people put the price of the housing too high. Here, you will
have trouble convincing the users of Tor or Namecoin that it is right
to pay 185 000 $ for a TLD and that, if they cannot afford it, they
have to stay in the slums.

[End of political rant, sorry]

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 3 Feb 2014 08:15:10 -0800

> [End of political rant, sorry]

Your political rant is, however, off-base. Assume for the moment that the Tor folks had registered oniontld.fr for a relatively small amount of money. It could have all of the attributes of .onion: you could hard-wire it into local resolvers, some requests for it would leak to the DNS and therefore possibly be trackable, and so on. For the purposes given in draft-grothoff-iesg-special-use-p2p-names, unsquatted FQDNs would work just as well as squatted TLDs.

--Paul Hoffman

---

From: Joe Abley <[email-masked]>
Date: Mon, 3 Feb 2014 15:35:13 -0500

> Your political rant is, however, off-base. Assume for the moment that the Tor folks had registered oniontld.fr for a relatively small amount of money. It could have all of the attributes of .onion:…

I made that point somewhat earlier (but my example was onion.eff.org or something).

The reasonable response to my instance of that observation was that there's a significant deployed base of users already making use of .onion [1], and we don't have a time machine that we're aware of [2] to allow that to be fixed.

Despite the enduring (and endearing, perhaps) optimism that the new gTLD programme would eventually bear fruit, I don't think it's unreasonable to think that in 2002 [3] a new gTLD wasn't really a practical option to choose not to take.

So squatting doesn't sound right to me.

Joe

[1] https://metrics.torproject.org
[2] http://www.huffingtonpost.co.uk/2012/07/02/stephen-hawking-time-travel_n_1643488.html
[3] http://en.wikipedia.org/wiki/Tor_(anonymity_network)#History

---

From: Mark Andrews <[email-masked]>
Date: Tue, 04 Feb 2014 08:23:33 +1100

In message <[email-masked]>, Joe Abley writes:
> > Your political rant is, however, off-base. Assume for the moment that
> > the Tor folks had registered oniontld.fr for a relatively small amount of
> > money. It could have all of the attributes of .onion: you could hard-wire
> > it into local resolvers, some requests for it would leak to the DNS and
> > therefore possibly be trackable, and so on. For the purposes given in
> > draft-grothoff-iesg-special-use-p2p-names, unsquatted FQDNs would work
> > just as well as squatted TLDs.
>
> The reasonable response to my instance of that observation was that
> there's a significant deployed base of users already making use of .onion
> [1], and we don't have a time machine that we're aware of [2] to allow
> that to be fixed.
>
> Despite the enduring (and endearing, perhaps) optimism that the new gTLD
> programme would eventually bear fruit, I don't think it's unreasonable to
> think that in 2002 [3] a new gTLD wasn't really a practical option to
> choose not to take.
>

They choose to use a TLD.  There were plenty of people saying "Do
NOT use a TLD for your private namespace, use a namespace you own"
in 2002 whether it was for a protocol or a internal network.

For $20 a year or less they could have registered a name in just
about any TLD and avoided the issue.

> [2] =
> http://www.huffingtonpost.co.uk/2012/07/02/stephen-hawking-time-travel_n_1=
> 643488.html
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Feb 2014 16:56:38 -0500

> in 2002 whether it was for a protocol or a internal network.

This is a useless discussion.   Recriminations do not change the past.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 3 Feb 2014 17:15:06 -0500

> This is a useless discussion.   Recriminations do not change the past.

True, but effectively what you're saying is that this special-use
registry could be used by anyone who's prepared to [squat|use a TLD
without registering it] in the right ways to get around the ICANN
allocation procedures.  I think that's spelled "moral hazard" in
economics.

A

-- 
Andrew Sullivan
[email-masked]

---

From: <[email-masked]>
Date: Mon, 3 Feb 2014 21:54:41 +0000

Hi everybody,

(just for full closure - I'm the IETF technical liaison to the ICANN
board, but taking that hat off here)

>about any TLD and avoided the issue.

I think we have to distinguish here between the "new squatters" and the
"old squatters" and the reasons for "squatting". For instance in corp and
home, the installed base seems to be quite large. It comes from equipment
and hardware that might not be easily replaceable and not really under a
single organization's control. You cannot change that and ignoring it
might cause harm for the Internet.

The new technologies (gnu/onion/...) seem to be different. First of all,
they don't use DNS but something else. Therefore, there should be no
collisions. It seems more that delegating them to the DNS would harm those
technologies rather than DNS or Internet getting harmed. The only
relationship to the DNS seems to be that they happen to have a structure
that is similar to the FQDN.

Anyways, I have been following this discussion now for a while. It seems
to me that the discussion is not really converging. I would blame it at
least partly on RFC6761. Though, RFC6761 isn't that old, it was written in
a time before the new gTLD round was ongoing.

Rather than discussing the individual strings, maybe we should consider to
discuss the principles under which TLDs can be reserved for special use
and consider a re-spin or an update to RFC6761.

Cheers,

Jonne.

>_______________________________________________
>DNSOP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dnsop

---

From: George Michaelson <[email-masked]>
Date: Tue, 4 Feb 2014 08:56:22 +1000

I am not personally convinced by "there are too many people committed"
arguments. I never have been, and I think the chilling effect of this has
been seen time and again.

There has always been "too many people" doing things. Claiming the dead
hand of history prevents us from changing course or deploying new things is
just wrong.

1 create onion.something.else and mark .onion as suitable for future use
under gTLD, if not now
2 release new TOR code and declare sunset period
3 wait for sunset period
4 stop blocking release of .onion

We don't expect people to use rlogin or rsh any more. Protocols move on.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Feb 2014 18:17:46 -0500

> We don't expect people to use rlogin or rsh any more. Protocols move on.

RSH was horrifically broken.   .onion makes a few IETFers feel a little dirty.   It's not the same situation.

---

From: George Michaelson <[email-masked]>
Date: Tue, 4 Feb 2014 09:27:09 +1000

Its a scaling question. Please don't sidetrack into distaste, its the
question of preventing progress by saying "too many" when in fact, its
tractable, and its software.

.onion is an eminently tractable problem. Arguing otherwise is to argue the
current .onion codebase dependency cannot move, therefore any future CVE
against TOR cannot be fixed, therefore further code development on TOR is
fruitless, therefore lets all stop coding. Breathing even.

This IETF mantra of "too many to change" is wrong. We need to stop invoking
the dead weight of the past over future events.

---

From: "John Levine" <[email-masked]>
Date: 4 Feb 2014 00:01:10 -0000

>allocation procedures.  I think that's spelled "moral hazard" in

Not really, because what you get by squatting on a TLD is nothing like
what you get if you rent it from ICANN.  Squats are all local
(mis-)use, with names only leaking onto the public Internet by
accident. 

It also seems implicit in this document that the plan is only to add
names to the registry if there is existing evidence that they're
significantly squatted, by which time it's too late anyway.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 3 Feb 2014 19:11:37 -0500

> (mis-)use, with names only leaking onto the public Internet by

That actually depends on what you're doing with the name.  In the case
of the names discussed in the chapin draft, that is true.  It's less
true in all cases.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Feb 2014 20:08:59 -0500

On Feb 3, 2014, at 6:27 PM, George Michaelson <[email-masked]> wrote:
> .onion is an eminently tractable problem. Arguing otherwise is to argue the current .onion codebase dependency cannot move, therefore any future CVE against TOR cannot be fixed, therefore further code development on TOR is fruitless, therefore lets all stop coding. Breathing even.\

What I'm saying is that it's an obnoxious thing to do, and there's no good reason to do it.   We really ought to have a good reason to demand that an organization over which we exert no control at all make a significant and incompatible change to their deployed code purely on the basis that some of us don't like what they did.   We need a better reason than that, and thus far none has been stated.

---

From: George Michaelson <[email-masked]>
Date: Tue, 4 Feb 2014 11:18:59 +1000

ok. I see where you are. I can be there, somewhat. Thats not a bad position
Ted.

So my sense of this is "you were advised not to do this, and you didn't
respect the process" for some value of "you"

What I don't like about that is a schoolmarm/punitive voice. But it has the
qualities. Tragedies of the commons don't just take one form, and having
s/w develop a dependency on name/locator properties with high visibility,
without considering the commons, is (in my opinion) a tragedy.

I'm not inherently arguing for ICANN process, or even the DNS. I think a
mature sense of the locator/id separation qualities of any endeavour, and
the arguments around naming, lead you to caution in seizing names in any
space.

IETF is constantly advised by w3c people (mark nottingham?) to be mindful
of the URI/URL concept, and not to over-egg stipulations on what is
meaningful in that space. And I think by and large, thats right.

So is what the TOR people did usurping .onion respectful of process? What
do you do, when process isn't respected?

-G

On Tue, Feb 4, 2014 at 11:08 AM, Ted Lemon <[email-masked]> wrote:

> > .onion is an eminently tractable problem. Arguing otherwise is to argue
> the current .onion codebase dependency cannot move, therefore any future
> CVE against TOR cannot be fixed, therefore further code development on TOR
> is fruitless, therefore lets all stop coding. Breathing even.\
>
> What I'm saying is that it's an obnoxious thing to do, and there's no good
> reason to do it.   We really ought to have a good reason to demand that an
> organization over which we exert no control at all make a significant and
> incompatible change to their deployed code purely on the basis that some of
> us don't like what they did.   We need a better reason than that, and thus
> far none has been stated.
>
>

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 3 Feb 2014 20:21:48 -0500

On Mon, Feb 03, 2014 at 08:08:59PM -0500, Ted Lemon wrote:
> 
> purely on the basis that some of us don't like what they did.  We
> need a better reason than that, and thus far none has been stated.

In the particular case of .onion, I'm not sure I agree none has been
stated.  But let me try again:

    If you want to use a name in DNS protocol slots, then you need a DNS
    name.  You didn't get a DNS name, and instead you used a label
    that wasn't under your control.  That's been against the rules in the
    DNS since forever.  Now you want to short-circuit the allocation
    mechanism.  But we have an allocation mechanism for this.  In the
    normal case, you apply to ICANN.  In an unusual case where the
    protocol depends on this, then you can use this special-use
    registry.  So you need to show that your protocol needs to depend
    on this special-use label, and then we can register it under the
    special use mechanism.  Otherwise go to ICANN.

What we ought to be arguing about, in effect, is precisely why this
needs a special-names registration.  Now, _maybe_ there is an argument
that this is a DNS-looking series of labels but it never goes into the
DNS namespace (that's what I've heard once).  In that case, there
might be an argument.  ("Put this in the default local zones, always
NXDOMAIN, because we want to protect the DNS.")  Maybe the argument is
instead that sometimes these names are handed to DNS resolvers and are
supposed to resolve.  In _that_ case, it seems to me that the "this is
a DNS name" consideration is also pretty high.  I'm unsure we've had
clear and consistent arguments about this for each of the cases.

In the chapin draft, the argument is different, and it appears to be
purely a local-resolution-only one -- that is, always "protection of
the DNS" because of de facto resolution and security decisions
deployed on the Net.  I haven't read it closely enough to decide
whether this is true for every label in the list.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Feb 2014 20:27:32 -0500

On Feb 3, 2014, at 8:18 PM, George Michaelson <[email-masked]> wrote:
> So is what the TOR people did usurping .onion respectful of process? What do you do, when process isn't respected?

Until recently there wasn't a process, and they seem to have tried to follow the process that now exists, in a pretty reasonable timeframe.   You can definitely ask them for more documentation.   If your ask is reasonable, and seems beneficial, there's a decent chance they'll do it.   But if your ask is unreasonable, you'll get ignored, and rightly so.   I think asking them to change .onion without a solid reason (not "you didn't follow process") is in the latter category.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Feb 2014 20:32:04 -0500

On Feb 3, 2014, at 8:21 PM, Andrew Sullivan <[email-masked]> wrote:
>    that wasn't under your control.

This is the "you didn't follow process" argument.   But they couldn't have followed process—there was no realistic process for allocating a special-use TLD before 6761 was published.   So this amounts to an emotional appeal, which isn't much of a justification for the change you are demanding of them.

I absolutely get why you are saying this.   It's a pretty good emotional appeal.   But we shouldn't act on it, because that's all it is.   We have a process, and they are following it.   We should see it through.

---

From: <[email-masked]>
Date: Tue, 4 Feb 2014 01:45:11 +0000

Hi Andrew,

>    special use mechanism.  Otherwise go to ICANN.

In addition, I would say that perhaps the current rules are targeted
towards DNS (or extensions of DNS as mDNS could be considered). These new
protocols are something else. They are not DNS and not even specified in
the IETF. They have taken a design choice where they look like DNS and
therefore, may clash with the DNS namespace. The aspect of reserve these
or you'll break the Internet (in some definition of break) isn't really
valid. It is more that you interfere with the functionality of these
protocols, which is a different magnitude of a problem. Perhaps, it is a
different problem all together.

>clear and consistent arguments about this for each of the cases.

Right. From there comes the question that if this is a way to work around
the process we have in the Internet now - you want a TLD you go to ICANN.
Regardless of what people think of that process, this is the process we
have created already a long time ago and it has been operational since the
beginning of ICANN. There is no other process to get TLDs.
 
>whether this is true for every label in the list.

Completely agree. The Chapin draft is trying to protect the Internet by
reserving names that for various reasons have collisions in the Internet.
It would be nice to remove these collisions, but it seems to be currently
impossible. So, this is a way to deal with a real problem in the Internet
we have today and avoid that these names would be delegated and cause
breakage in the Internet.

I also believe these two cases should be considered very separately.

Cheers,

Jonne.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 3 Feb 2014 20:50:27 -0500

On Mon, Feb 03, 2014 at 08:32:04PM -0500, Ted Lemon wrote:

> This is the "you didn't follow process" argument.  But they couldn't
> have followed process—there was no realistic process for allocating
> a special-use TLD before 6761 was published.  So this amounts to an
> emotional appeal, which isn't much of a justification for the change
> you are demanding of them.

The DNS works -- has _always worked_ -- on the principle that you
register your names if you want to use them on the Internet.  This is
just as true of top level names as of anything else.  It is true that
when .onion (to stick to our example) was adopted, there wasn't a
mechanism other than going to ICANN to get a TLD.  (There certainly
was a mechanism via the ICANN route at the time.)  I'm not sure how to
interpret this part of your argument except, "If the mechanism for
what you want to do doesn't exist or is too inconvenient, just do
whatever you want."  That has interesting implications for the IANA
function.

Moreover, 6761 is _perfectly clear_ that you're supposed to show that
your use actually requires a TLD.  I still don't see why .onion.arpa
would've been a bad choice.  Failing to answer that question really
_would_ be not following the process.

Finally, mine at least is not just an emotional argument; see above,
variations of which I have repeated.  Indeed, whether you intend it or
not, your mails appear to me to be rather emotionally charged and
dismissive of any pointy question or suggestion that the interests of
the rest of the DNS (including the root management regime) need to be
taken into consideration as well.  It seems to me that you could read
with a more generous application of the principle of charity.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 4 Feb 2014 06:39:11 -0000

>of the names discussed in the chapin draft, that is true.  It's less

I think that all we're talking about here is reserving domain names
and saying that they should never resolve on the global Internet.

If the IETF finds good technical reasons to reserve some other name
for some other reason, e.g., peer to peer exchange of crypto
credentials or something, so what?  It's one less name for ICANN to
sell but I don't see why that would be our problem.

I suppose the situation with .onion is slightly different, but in
concept it's not all that different from .arpa.  It's a domain that
people are using for special technical purposes, so it's not available
for normal delegation.  The only ICANN delegated name that's the least
bit interesting is .TEL, an attempt to create an online directory
using NAPTR that is a failure, so they're unlikely to do any more.

R's,
John

PS: Because I am not a good person, you can reply to me at
[email-masked].  Or, of course, [email-masked].

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 04 Feb 2014 07:43:36 +0100

>     that wasn't under your control.

I would like to express the situation slightly different, or rather,
this what you describe is one situation. Another situation which I think
is more complicated is when a name is needed that looks like a domain
name, but is never to be used in DNS. The only thing you need is a
string that is not used as a domain name.

So we have (at least):

1. Strings that are used in DNS, allocated as they where intended to be
allocated

2. Strings that are to be used in DNS, with special roots

3. Strings that are to be used in DNS, but only in local environments
(search path, .local etc)

4. Strings that looks like domain names but are never to be used in DNS,
but still needs to be globally unique

5. Strings that looks like domain names but are never to be used in DNS,
that does not need to be globally unique

We know about 1. We say no to 2. We know about 3. What is new is 4 and 5.

   Patrik

---

From: Jim Reid <[email-masked]>
Date: Tue, 4 Feb 2014 08:22:54 +0000

>    special use mechanism.  Otherwise go to ICANN.

+100.

I hope everyone here can agree on the above and we get back to discussing the actual draft.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 4 Feb 2014 09:40:45 +0100

On Tue, Feb 04, 2014 at 08:23:33AM +1100,
 Mark Andrews <[email-masked]> wrote 
 a message of 62 lines which said:

> There were plenty of people saying "Do NOT use a TLD for your
> private namespace, use a namespace you own" in 2002 whether it was
> for a protocol or a internal network.

Hmmm, the experience of many developers is that, no, it is not easy to
get advice from the IETF. Some did not even bother but those who did
were often turned down immediately. 

Let's play an experiment. In 2014, Joe Developer has a bright idea of
using cryptographic keys as domain names (yes, I know, there is
already the zkeys of GNUnet), he is going to write code to implement
it and wants a suffix for that, to be sure his domain names won't
collide with the ICANN root. Knowing nothing about Internet
governance, not having 185 000 US $ and a zillion lawyers at his
disposal to request a TLD, not being Apple, with the ability to squatt
a TLD and deploy it massively, he sends an email to dnsop or
namedroppers asking about advice. What happens?

1) (Most likely) He gets no reply at all because nobody knows him and
he never appeared in an IETF meeting

2) He gets a few messages saying "that's a bad idea, don't do that,
for reasons explained in [insert a long list of RFC]"

3) He gets a ton of messages saying it is a stupid idea and he is
endangering the security and stability of the Internet

4) He gets a sensible advice, based on a careful study of his
proposal, and given by people who forgives him for making a few
mistakes such as not being able to know what is the difference between
IETF and ICANN

In the first three cases, what will he do? He will follow the usual
Internet/free software method, implement and distribute and we'll see
what happens. And then it will be too late to change what's in his
code.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 4 Feb 2014 09:42:59 +0100

On Mon, Feb 03, 2014 at 09:54:41PM +0000,
 [email-masked] <[email-masked]> wrote 
 a message of 112 lines which said:

> maybe we should consider to discuss the principles under which TLDs
> can be reserved for special use and consider a re-spin or an update
> to RFC6761.

So, RFC 6761 was written just to allow Apple to register .local and,
once it is done, we close the door to new registrations?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 4 Feb 2014 09:51:34 +0100

On Tue, Feb 04, 2014 at 01:45:11AM +0000,
 [email-masked] <[email-masked]> wrote 
 a message of 88 lines which said:

> They are not DNS and not even specified in the IETF. They have taken
> a design choice where they look like DNS

No, that's not a correct description. These proposals use domain names
(not things that "look like" domain names). Domain names are *older*
than the DNS (see RFC 810 and many others). They can be resolved by
several protocols (DNS, Bonjour, /etc/hosts, LDAP, whatever). It is
perfectly sensible to use domain names for new protocols.

> you want a TLD you go to ICANN.  Regardless of what people think of
> that process, this is the process we have created already a long
> time ago

If "we" is the US governement, the sentence is true. Otherwise, no, I
had no part in the ICANN creation. I remember a discussion with Stuart
Cheshire where he explained that IETF, not ICANN, created the entire
name space, since it created the rules, and therefore has rights above
those of ICANN.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 4 Feb 2014 05:29:56 -0500

> name space, since it created the rules, and therefore has rights above

With respect, while that is one view of the history, it is surely not
the only one, and it seems to me it is one that is not shared by all
the actors in this space.  Most importantly, it involves a false
dichotomy between "ICANN" and "IETF": neither organization existed at
the time the DNS name space was created, so it's hard to credit the
idea that either of them created the name space.

I do not think we want to turn over the rock labelled, "Who owns the
DNS name space?"  Under that rock live all manner of creatures from
layer 9 and above.  We have two allocation procedures: regular
allocation via IANA procedures (which happen to be defined right now
in ICANN) and RFC 6761.  One of those procedures is the one we can
exercise, and I still believe the only question is whether any
particular registration attempt works under RFC 6761.  I agree with
Ted Lemon that the question of what happened in the past is not
exactly relevant.  What _is_ relevant in my view is how these names
need to be used in support of the protocols they're supposed to be
supporting.  This is exactly the same question I had since I first
read the grothoff draft; see my earlier review.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Joe Abley <[email-masked]>
Date: Tue, 4 Feb 2014 09:41:16 -0500

On 2014-02-04, at 01:39, John Levine <[email-masked]> wrote:

> concept it's not all that different from .arpa.

I think it's quite different.

ARPA is really no different from any other TLD. There's a registry, there are rules you need to follow to get a delegation, but it's a zone in the DNS just like COM and ORG.

ONION is a namespace convention outside the DNS. There's no registry, it's not a zone, and there is no possibility of getting a delegation.

ONION is like LOCAL. Neither are like ARPA (or any other TLD).

Joe

---

From: Paul Vixie <[email-masked]>
Date: Tue, 04 Feb 2014 07:00:26 -0800

Joe Abley wrote:
> ...

How like LOCAL is ONION? ICANN knows it can't sell .LOCAL, but does
ICANN know it can't sell .ONION ?

---

From: Joe Abley <[email-masked]>
Date: Tue, 4 Feb 2014 10:15:05 -0500

On 2014-02-04, at 10:00, Paul Vixie <[email-masked]> wrote:

> How like LOCAL is ONION?

Neither is a zone in the DNS or a domain in the DNS namespace, and both refer to names for which a protocol other than DNS should be used for resolution.

(I realise the protocol for LOCAL is DNS-like, but it's not DNS, right?)

> ICANN knows it can't sell .LOCAL, but does

I was never quite sure what ICANN knew, even when I worked for ICANN.

I'm not arguing against the IETF protecting the world from conflicting ONION namespaces in the same way that they did with LOCAL, which would have the effect that ICANN would not sell ONION. I agree that if ICANN sold ONION to someone, the result would be messy.

However, I don't think ambiguity in the discussion about the namespaces we're talking about or the failure modes we're hoping to avoid helps us narrow in on anything resembling consensus.

Joe

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 04 Feb 2014 07:17:21 -0800

On 2/4/2014 7:00 AM, Paul Vixie wrote:

> How like LOCAL is ONION? ICANN knows it can't sell .LOCAL, but
> does ICANN know it can't sell .ONION ?

I think I see where Vixie is going with this, and I concur. I don't
see the difference either, and simply because .onion started being
used before a contrarian policy was in place should not be reason
enough to dispense with it's use.

$.02,

- - ferg

- -- 
Paul Ferguson
VP Threat Intelligence, IID
PGP Public Key ID: 0x54DC85B2

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 4 Feb 2014 10:42:52 -0500

Dear Colleagues,

On Feb 4, 2014, at 5:29 AM, Andrew Sullivan <[email-masked]> wrote:
> particular registration attempt works under RFC 6761. 

In this spirit, I'd like to suggest that we assume for the sake of the current discussion that any apparent problem between ICANN and the IETF over the public DNS namespace can be resolved sensibly, so it's unnecessary to speculate on what ICANN knows, or what applicants for names under ICANN's process will or won't do, or whose process has precedence.

I think our job here has to be to discuss these drafts on their merits-- the operational impact of adding these names to the special use registry, or not, including guidance to implementors (if we converge on any) and precedents for other protocol and software developers in the future.

It also seems to me that if we come up with refinements or modifications to RFC 6761, we can write those up and share them with the community in the usual way.

best,
Suzanne

---

From: "John Levine" <[email-masked]>
Date: 4 Feb 2014 23:40:37 -0000

>using cryptographic keys as domain names

Yup, that would be .bit.  Everything you say is true.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 5 Feb 2014 00:53:34 -0000

>> How like LOCAL is ONION?
>
>Neither is a zone in the DNS or a domain in the DNS namespace, and both refer to names for which a
>protocol other than DNS should be used for resolution.
>

The protocol for .ONION is DNS-like, too.  If you're running Tor, its
SOCKS proxy handles the domain names, using the normal SOCKS5
protocol, with .ONION and .EXIT treated as special cases.  The client
software, typically a web browser, doesn't know it's any different
from any other SOCKS proxy.

It seems to me that we can make a meaningful distinction between
domain names that are delegated from the global root using the normal
DNS protocol and allow arbitrary RRs (give or take) which is ICANN's
department, and domain names that are handled in other ways which is
the IETF's.  The only ICANN domain that isn't technically totally
ordinary is .TEL, which was supposed to be a directory using NAPTR to
map names to phone numbers.  It is quietly slouching toward genericity
with rather a lot of names parked by speculators, so I doubt we'll see
any more of those from ICANN.

I realize that the received wisdom is that any variation from the
standard protocol is awful and must be eliminated with extreme
prejudice, but that horse left the barn a long time ago, and enough
people have seen it running around and looking healthy that we have a
credibility problem.

What does cause problems is name collisions, but we can deal with them
more effectively with registries than by trying to stamp out pseudo-TLDs
named .ONION and .BIT and who knows what else.

R's,
John, formerly aka [email-masked], currently [email-masked].

PS: Andrew asked whether .onion.arpa would have worked technically as
well as .onion.  Sure.  But so what?

---

From: joel jaeggli <[email-masked]>
Date: Tue, 04 Feb 2014 17:06:11 -0800

> once it is done, we close the door to new registrations?

That in and of itself would be a bit of a moral hazard. it's plausible
that this one case is simply more clear cut (certainly in the minds of
the authors) then others.

I don't believe that we did this (6761) so that we could treat this as a
one-off event.

it's my personal opinion that application specific namespaces should be
treated differently in some way, if resolver libraries are being asked
to make a decision on the basis of .tld how to handle a query we gone
down an extensibility rathole that's hard to get out of.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Feb 2014 07:39:31 -0500

On Feb 4, 2014, at 8:06 PM, joel jaeggli <[email-masked]> wrote:
> resolver libraries are being asked

Lookup tables are hard...

:)

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 24 Feb 2014 17:51:43 -0800

On 29 Jan, 2014, at 07:47, Ralf Weber <[email-masked]> wrote:

> Where shall this stop? How about .LOKALESNETZWERK (german for .LAN). How many domains do we want to treat special? I know this draft only asks for 8, but some of them are on ICANNs application list.

Currently, with no established procedure for local-use names, the result is chaos. Since no DNS equivalent to RFC 1918 exists, people use whatever name they feel like. My hope is that if people are offered a short list of legitimate pseudo-TLDs for local-use names, the temptation to use some other TLD not on that list will be less. Today all NAT gateways I know of default to one of the RFC 1918 address ranges. If RFC 1918 did not exist, would NAT gateways not exist, or would they just hijack who-knows-what addresses? I suspect the latter.

If we acknowledge and document the reality, the IETF can have a role in guiding it in a sane direction. If we pretend local-use names don’t exist, then the IETF has less relevance in the real world and the real world carries on without us.

> I also don't think there are risks in delegation these other than the applicants will get lots of traffic.

No, the risk is that the applicants *won’t* get the traffic they want, because some user’s local DNS is answering those queries.

If we have *some* pseudo-TLDs reserved for local-use names, there’s a stronger argument that local hijacking of other names is illegitimate.

And yes, if you want .LOKALESNETZWERK, then argue for that. Let’s use this IETF discussion process to get some clarity on which names are local-use and which ones are not.

Stuart Cheshire

---

From: Mark Andrews <[email-masked]>
Date: Tue, 25 Feb 2014 14:37:08 +1100

In message <[email-masked]>, Stuart Cheshire wr
ites:
> > Where shall this stop? How about .LOKALESNETZWERK (german for .LAN).
> > How many domains do we want to treat special? I know this draft only asks
> > for 8, but some of them are on ICANNs application list.
>
> Currently, with no established procedure for local-use names, the result
> is chaos. Since no DNS equivalent to RFC 1918 exists, people use whatever
> name they feel like. My hope is that if people are offered a short list
> of legitimate pseudo-TLDs for local-use names, the temptation to use some
> other TLD not on that list will be less. Today all NAT gateways I know of
> default to one of the RFC 1918 address ranges. If RFC 1918 did not exist,
> would NAT gateways not exist, or would they just hijack who-knows-what
> addresses? I suspect the latter.

There is a slight difference.  There is no restriction on getting
names other than unwillingness or lack of education about how to
get a name.  There is a real restriction on getting enough IPv4
addresses to avoid having to use NAT.

With IPv6 you don't even need split DNS.

They can alway use <name>.10.in-addr.arpa. 10.in-addr.arpa is a
perfectly legal suffix for a hostname and 10.in-addr.arpa has a
insecure delegation so there are no DNSSEC issues.  Additionally
the AS112 server will soak any leaked names.  It's not as
pretty as .home or .lan or .corp or .... but it will work.

Alternatively get home.arpa insecurely delegated to a AS112 style
server.  <hostname>.home.arpa. isn't too bad and matches the hostname
structure of 99% of the corporate work, <hostname>.<label>.<tld>.

This also has the advantage that it doesn't involve root zone
politics.

Mark

> If we acknowledge and document the reality, the IETF can have a role in
> guiding it in a sane direction. If we pretend local-use names don't
> exist, then the IETF has less relevance in the real world and the real
> world carries on without us.
>
> No, the risk is that the applicants *won't* get the traffic they want,
> because some user's local DNS is answering those queries.
>
> If we have *some* pseudo-TLDs reserved for local-use names, there's a
> stronger argument that local hijacking of other names is illegitimate.
>
> And yes, if you want .LOKALESNETZWERK, then argue for that. Let's use
> this IETF discussion process to get some clarity on which names are
> local-use and which ones are not.
>
> Stuart Cheshire
>

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 25 Feb 2014 19:59:29 -0800

On 24 Feb, 2014, at 19:37, Mark Andrews <[email-masked]> wrote:

> get a name.

Good point. A document to help this education aspect would be good.

> They can alway use <name>.10.in-addr.arpa.

I think human-interface factors make such names a non-starter. The people doing this want memorable easy-to-type names.

Stuart Cheshire

---

From: Mark Andrews <[email-masked]>
Date: Wed, 26 Feb 2014 15:50:20 +1100

In message <[email-masked]>, Stuart Cheshire wr
ites:
> I think human-interface factors make such names a non-starter. The people doi
> ng this want memorable easy-to-type names.

<name>.10.in-addr.arpa. was a bit tongue in cheek, but <name>.home.arpa
I think could be a viable alternative for those that refuse to get
their own domain.  It would require a education process but I think
it would be possible.

---

From: David Conrad <[email-masked]>
Date: Wed, 26 Feb 2014 16:16:30 +0800

On Feb 25, 2014, at 9:51 AM, Stuart Cheshire <[email-masked]> wrote:
> If we have *some* pseudo-TLDs reserved for local-use names,

I would think http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#User-assigned_code_elements would be appropriate for this purpose.

Regards,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Wed, 26 Feb 2014 21:03:11 +1100

In message <[email-masked]>, David Conrad
 writes:
> I would think =
> http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#User-assigned_code_element=
> s would be appropriate for this purpose.
> 
> Regards,
> -drc

Whatever is used needs to be insecurely delegated so that in app
validation will work.

Mark

---

From: Joe Abley <[email-masked]>
Date: Wed, 26 Feb 2014 09:34:02 -0500

> Whatever is used needs to be insecurely delegated so that in app

I still don’t see why we need a TLD, or a delegation/reservation under ARPA.

There are many, many TLDs under which an application/protocol implementer can reserve some namespace for their exclusive use at low cost ($10/year, say). Why is this approach not preferred for a new application/protocol? It seems far simpler.

Perhaps all that is missing is some guidance that says “you shouldn’t hijack namespaces that you don’t control, even for non-DNS applications; register a domain instead”.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 26 Feb 2014 07:28:55 -0800

> Perhaps all that is missing is some guidance that says “you shouldn’t hijack namespaces that you don’t control, even for non-DNS applications; register a domain instead”.

+1, with a short list of things that can go wrong if you hijack. I'd be willing to write that up (maybe with Joe; his sardonic humor is more fun than mine) if people here think it would move forward as an update to RFC 6761.

--Paul Hoffman

---

From: David Conrad <[email-masked]>
Date: Thu, 27 Feb 2014 07:19:38 +0800

Joe,

> I still don’t see why we need a TLD, or a delegation/reservation under ARPA.

Because if something isn't documented, people tend to squat.

> There are many, many TLDs under which an application/protocol implementer can reserve some namespace for their exclusive use at low cost ($10/year, say). Why is this approach not preferred for a ne…

Why does RFC 1918 address space exist?

Regards,
-drc

---

From: "John Levine" <[email-masked]>
Date: 26 Feb 2014 23:39:07 -0000

>Perhaps all that is missing is some guidance that says “you shouldn’t hijack
>namespaces that you don’t control, even for non-DNS applications; register a
>domain instead”.

That's a relatively high bar for all the residential broadband users
who buy a router at Best Buy (Future Shop to you), plug it in, and set
up the router via the configuration page at http://router.home.

What do they get for their $10/yr and extra config hassle that they
would care about?

R's,
John

PS: Don't miss ICANN's latest on this point:

http://www.icann.org/en/news/announcements/announcement-26feb14-en.htm

They commissioned a report that says to reserve .HOME .CORP and .MAIL,
and to do a 120 day wildcard on new domains that returns 127.0.53.53
to alert people to upcoming problems and see what the traffic is.  It
notably does not suggest how to interpret the results after the 120
days.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Feb 2014 13:14:36 +1100

In message <[email-masked]>, David Conrad
 writes:
> > I still don't see why we need a TLD, or a delegation/reservation under
> ARPA.
>
> > There are many, many TLDs under which an application/protocol
> implementer can reserve some namespace for their exclusive use at low
> cost ($10/year, say). Why is this approach not preferred for a new
> application/protocol? It seems far simpler.
>

Because IPv4 address were and always have been a scarse resource
and RFC 1918 is a reaction to that.  Homes use it because CPE vendors
built it into their devices because

	* Lots of ISP's would only give you one address
	* Those that didn't often charged you a lot
	* Ridiculous ISP terms and conditions that prohibited multiple
	  machines.

> Regards,
> -drc
> 
> 
> --Apple-Mail=_196EAF71-9F8C-416D-8D37-7BD2EBF86381
> Content-Transfer-Encoding: 7bit
> Content-Disposition: attachment;
> 	filename=signature.asc
> Content-Type: application/pgp-signature;
> 	name=signature.asc
> Content-Description: Message signed with OpenPGP using GPGMail
> 
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> 
> iQEcBAEBAgAGBQJTDnaKAAoJENV6ebf0/4rXSUgH/jz+HlRsm7xmjLRg0RP/vHAn
> j9WnJB5RASC7wjTmj/KplNQzyMZvmgSwcF8NlZNwE9/L/pUA8bjguj2nMni/irnw
> 73BA/39fc1vlFNi6n1UuTEjFx9w2fYoxFk2x0Zjf2xd0U/THJhWisggFohXy0T5H
> 0iGIpAAr07Kj3y1QR0R59TMjZ0usxLDd0V9CZdoZcJzwRyqCFrJJS7twLtDvYWyl
> xmUPViNyeRbw8tbnHKFiGukGgeZeccjDF6qiSFlsKP1zPJAScUE4+9PC+JGCDrN+
> ScyLGer3DOh5mVvFwENwwXeRHvoBQsml9byI8FkDqGB+r1ChuTqGHs3VP1UcY2Q=
> =1Gi3
> -----END PGP SIGNATURE-----
> 
> --Apple-Mail=_196EAF71-9F8C-416D-8D37-7BD2EBF86381--
> 
> 
> --===============0999451085410326449==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --===============0999451085410326449==--
>

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Feb 2014 13:56:16 +1100

In message <[email-masked]>, "John Levine" writes:
> 
> >Perhaps all that is missing is some guidance that says "you shouldn't hijack
> >namespaces that you don't control, even for non-DNS applications; register a
> >domain instead".
> 

And why wasn't that "http://router.netgear.com" or
"http://router.linksys.com". The router could easily serve the zone
locally and the vendor could have a insecure delegation to it so
it works if there are validating browsers being used.

http://router.home does not work with validating browsers.

If the CPE vendors want to use .home let them pony up the 100K for
it rather than hijack the namespace.

> --===============4405462344142669891==
> --===============4405462344142669891==--

---

From: "John Levine" <[email-masked]>
Date: 27 Feb 2014 03:19:21 -0000

>"http://router.linksys.com".

I dunno, but that doesn't help much once the network is online and
there are other devices with .home names.

>it rather than hijack the namespace.

Um, it's a wee bit late for that.

R's,
John

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 26 Feb 2014 19:37:35 -0800

On Feb 26, 2014, at 3:39 PM, John Levine <[email-masked]> wrote:

>> Perhaps all that is missing is some guidance that says �you shouldn�t hijack
>> namespaces that you don�t control, even for non-DNS applications; register a
>> domain instead�.
> 

Ummm, why do those people need to have a unique domain name at all?

> http://www.icann.org/en/news/announcements/announcement-26feb14-en.htm

That's unrelated to "this point", it seems.

--Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Feb 2014 14:42:41 +1100

> there are other devices with .home names.

Whether is it router.home or router.vendor.com, both names assume
that the CPE device is in the DNS lookup path to get the correct
address returned for the name.

If the CPE puts out a search list of "home.arpa" rather than "home"
in the DHCP lease and added the machines to home.arpa rather than
home zone I doubt many people would notice.  Most home users would
be using unqualified names and the resolver's search will qualify
them.

This is all about getting sensible defaults in new CPE devices and
have a reserved place for them.  This should already be configurable
if they doing this sort of thing.

---

From: David Conrad <[email-masked]>
Date: Thu, 27 Feb 2014 14:16:15 +0800

Mark,

On Feb 27, 2014, at 10:14 AM, Mark Andrews <[email-masked]> wrote:
> Because IPv4 address were and always have been a scarse resource and RFC 1918 is a reaction to that.  

Not really.  RFC 1918 was created when IPv4 addresses were still relatively plentiful.  Many folks used 1918 space because they didn't want to be bothered with putting up with the hassles and cost (even if it was trivial) of obtaining space from the registries for a resource that was never going to be used on the Internet.

There are a number of potential options for 'private' domain space. I do not believe the answer of "buy a domain" will alleviate the problem as paying money and wading through web forms, etc., will always be harder that simply squatting on a domain name.

Regards,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Feb 2014 18:42:49 +1100

In message <[email-masked]>, David Conrad
 writes:
> Not really.  RFC 1918 was created when IPv4 addresses were still
> relatively plentiful.  Many folks used 1918 space because they didn't
> want to be bothered with putting up with the hassles and cost (even if it
> was trivial) of obtaining space from the registries for a resource that
> was never going to be used on the Internet.

While there are multiple reasons, RFC 1918 does actually state that address
space is a scare resource.  

   The Internet has grown beyond anyone's expectations. Sustained
   exponential growth continues to introduce new challenges.  One
   challenge is a concern within the community that globally unique
   address space will be exhausted. A separate and far more pressing
   concern is that the amount of routing overhead will grow beyond the
   capabilities of Internet Service Providers. Efforts are in progress
   within the community to find long term solutions to both of these
   problems. Meanwhile it is necessary to revisit address allocation
   procedures, and their impact on the Internet routing system.

> There are a number of potential options for 'private' domain space. I do
> not believe the answer of "buy a domain" will alleviate the problem as
> paying money and wading through web forms, etc., will always be harder
> that simply squatting on a domain name.

Well hopefully DNSSEC will eventually be on by default and squatting
like this will have negative consequences.  There may be a need for
a reserved suffix.  It doesn't have to be .HOME.  Rewarding bad
behaviour leads to more bad behaviour.

---

From: Jim Reid <[email-masked]>
Date: Thu, 27 Feb 2014 11:45:52 +0000

On 27 Feb 2014, at 07:42, Mark Andrews <[email-masked]> wrote:

> DNSSEC will eventually be on by default and squatting like this will have negative consequences.

Er, no. Vendors who pluck domain names out of the ether and use them in their products will by definition not have the DNS clue required for deploying a viable DNSSEC. Besides, in the case of CPE, they won't even *need* DNSSEC because the offending domain names (router.home or whatever) get looked up on the internal net. Most likely those names will be used by web browsers that do not have a validating resolver and are already relying on the CPE for DNS. Those lookups will almost never go to the outside, far less validate a signed referral for .whatever from the root.

> There may be a need for a reserved suffix.  It doesn't have to be .HOME.  Rewarding bad

IMO, the draft aims to document existing bad behaviour and explains why people should stop doing those bad/stupid/wrong things. Or at least appreciate the consequences. This is a Good Thing. It might even mean fewer instances of bad behaviour in future. Whether of course the writers of CPE crapware will ever read this RFC, let alone act on it, is another matter. At least the IETF will have produced a useful document on the topic. Which is all it could do.

BTW, the latest thinking (ie as of yesterday) from ICANN is .home will be reserved indefinitely: http://www.icann.org/en/news/public-comment/name-collision-26feb14-en.htm. It doesn't matter now whether someone wants to call that "rewarding bad behaviour" or not. That train left the station a long, long time ago. [And I'm long past caring either way.] So it seems to me ICANN is acknowledging reality and taking prudent measures for overall security and stability of the DNS. Too much stuff is already (ab)using .home so this TLD can't go into the public root for the obvious reasons.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Feb 2014 22:55:18 +1100

In message <[email-masked]>, Jim Reid writes:
> Er, no. Vendors who pluck domain names out of the ether and use them in
> their products will by definition not have the DNS clue required for
> deploying a viable DNSSEC. Besides, in the case of CPE, they won't even
> *need* DNSSEC because the offending domain names (router.home or
> whatever) get looked up on the internal net. Most likely those names will
> be used by web browsers that do not have a validating resolver and are
> already relying on the CPE for DNS. Those lookups will almost never go to
> the outside, far less validate a signed referral for .whatever from the
> root.

And the moment you have a validating brower / app they *will* break.

> > There may be a need for a reserved suffix.  It doesn't have to be
> > .HOME.  Rewarding bad behaviour leads to more bad behaviour.
>
> IMO, the draft aims to document existing bad behaviour and explains why
> people should stop doing those bad/stupid/wrong things. Or at least
> appreciate the consequences. This is a Good Thing. It might even mean
> fewer instances of bad behaviour in future. Whether of course the writers
> of CPE crapware will ever read this RFC, let alone act on it, is another
> matter. At least the IETF will have produced a useful document on the
> topic. Which is all it could do.
>
> BTW, the latest thinking (ie as of yesterday) from ICANN is .home will be
> reserved indefinitely:
> http://www.icann.org/en/news/public-comment/name-collision-26feb14-en.htm.
>  It doesn't matter now whether someone wants to call that "rewarding bad
> behaviour" or not. That train left the station a long, long time ago.
> [And I'm long past caring either way.] So it seems to me ICANN is
> acknowledging reality and taking prudent measures for overall security
> and stability of the DNS. Too much stuff is already (ab)using .home so
> this TLD can't go into the public root for the obvious reasons.

reserved indefinitely != insecurely delegated

10.in-addr.arpa is insecurely delegated deliberately to prevent DNSSEC
breakages.

---

From: Jim Reid <[email-masked]>
Date: Thu, 27 Feb 2014 12:15:31 +0000

> And the moment you have a validating brower / app they *will* break.

And this is a problem because... ?

I doubt there will ever be validating browsers/apps for accessing CPE from the inside. They have no need for DNSSEC because everything's on the local net. But let's assume they do. The Netgear app could have a TA for .netgear (say) embedded in it. A more likely scenario is the software hard-wires a locally scoped IP address to the device and doesn't bother with DNS at all. Most CPE is already doing that as a fall-back in case local (unsigned) DNS is broken.

> reserved indefinitely != insecurely delegated

Not delegated at all == ???

> 10.in-addr.arpa is insecurely delegated deliberately to prevent DNSSEC

Sure. But that's in a part of the name space where end client behaviour is known, stable and predictable.

Are you suggesting IANA has to insert provably insecure delegations for every possible string that someone, somewhere might be informally using as a TLD? Good luck with that.

---

From: Tony Finch <[email-masked]>
Date: Thu, 27 Feb 2014 12:21:42 +0000

Jim Reid <[email-masked]> wrote:
> I doubt there will ever be validating browsers/apps for accessing CPE
> from the inside. They have no need for DNSSEC because everything's on
> the local net.

The problem occurs when common operating systems start shipping validating
resolvers, then users will not be able to browse to http://router.home to
configure their device.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty, Forth, Tyne, Dogger: Southwest 4 or 5, but south 6 to gale
8 at first in Forties and Dogger. Moderate or rough, occasionally very rough
at first in Forties and Dogger. Showers, rain at first. Moderate or good.

---

From: Jim Reid <[email-masked]>
Date: Thu, 27 Feb 2014 12:55:30 +0000

> resolvers, then users will not be able to browse to http://router.home to

An what do these users currently do when router.home or whatever doesn't resolve regardless of whether DNSSEC is involved?

IMO there is no actual problem apart from perhaps a minor inconvenience that's no different from the current (unsigned) failure mode.

Nothing to see here, move along...

---

From: Tony Finch <[email-masked]>
Date: Thu, 27 Feb 2014 13:17:06 +0000

Jim Reid <[email-masked]> wrote:

> An what do these users currently do when router.home or whatever doesn't
> resolve regardless of whether DNSSEC is involved?

They follow the troubleshooting guide and eventually get it to work.

With DNSSEC the only resolution would be to turn off validation on the
user's computer which is NOT what we want.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fisher, German Bight, Humber: South 6 to gale 8, becoming variable 4 later.
Moderate or rough, occasionally very rough at first in Fisher, becoming slight
later in German Bight and Humber. Rain or showers. Moderate or good.

---

From: Suzanne Woolf <[email-masked]>
Date: Thu, 27 Feb 2014 09:47:02 -0500

(chair bit enabled)

> it rather than hijack the namespace.

There are operational reasons to care whether a name is in the special names registry, the production root zone, both, or neither-- regardless of who has authority over either or on what terms. We should probably focus on those. The DNSSEC issue is one useful set to explore, and further focus on it would be helpful. Another set of suggestions for our work is beginning to appear around refinements of standards treatment for DNS search path processing, on the grounds that much of the unpredictability of mixing namespaces and DNS scopes is based on unpredictable precedence of search path processes.

We've attempted to suggest now more than once that the special names discussions will be more useful if:

*We leave speculation on the economics and other non-technical attributes of other entities' decisions about the namespace out of it. Speculation on other mechanisms besides the one we in the IETF have (roughly, RFC 6761) for getting names into the top level namespace isn't productive, as we don't control them. We don't know when or whether ICANN will ever conduct another new TLD opening, or what will be eligible to be included, or at what price. The root zone change we have to consider is only that the old assumptions about its size stopped applying, not what the new ones might be beyond the specific commitments made by ICANN in its current root zone expansion. This is not an endorsement of anyone's actions in this space, or a condemnation either; it's an attempt to describe the situation we're actually in. 

* We separate issues of "what should be done, if anything, in the future to enable/support/protect non-DNS-protocol-specific, possibly non-global uses of the DNS namespace" from "what should be done, if anything, to improve/normalize the situation we're currently in". We have several drafts for discussion in London on options for the future, and a possible course of action for them that we work on them as refinements or replacements to RFC 6761. We also have two drafts requesting more or less that we grandfather pseudo-TLDs deployed in the absence of clear guidelines and consistent system behavior, in order to mitigate current issues caused by "hijacking" names under traditional expectations about how the root zone is managed. 

Regarding the guidance Joe proposed, our question is whether it's good guidance for the future, not so much whether it would have been in the past. We may also decide there's nothing we can do in the way of such guidance, the relevant horses have left the relevant barns, and the combination of DNS on-the-wire protocol, system behavior for scoping of names, and the policy characteristics of the namespace mean ambiguity, collision, or other sub-optimal characteristics of trying to use DNS namespace for non-DNS protocols or non-global scopes are a fact of life we can't usefully act to prevent in the future. That doesn't tell the IESG what to do with the current requests for grandfathering.

Ultimately, these issues do have to be integrated. But at this point we will get nowhere in, for example, trying to decide whether to grandfather existing names into the special names registry managed under the process in RFC 6761 based on an opinion about what a vendor might or should do in the future under an ICANN process we don't control.

thanks,
Suzanne

---

From: "John Levine" <[email-masked]>
Date: 28 Feb 2014 04:19:55 -0000

>resolvers, then users will not be able to browse to http://router.home to

Since the device and the browser will not be online when you do the
initial configuration, it seems to me that if you use a validating
resolver you lose no matter what the name is.

R's,
John

---

From: Tony Finch <[email-masked]>
Date: Fri, 28 Feb 2014 11:31:26 +0000

> resolver you lose no matter what the name is.

Hmm yes a very good point :-/

I think this is an argument in favour of registering a special use name
for this purpose which can be configured with a negative trust anchor.

Unless someone has a bright idea for some alternative fix...

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Faeroes, South-east Iceland: Cyclonic 6 to gale 8, occasionally severe gale 9
at first in Faeroes. Very rough, occasionally high. Occasional rain. Moderate
or good.

---

From: Joe Abley <[email-masked]>
Date: Fri, 28 Feb 2014 10:06:20 -0500

On 28 Feb 2014, at 6:31, Tony Finch <[email-masked]> wrote:

> Unless someone has a bright idea for some alternative fix…

Bonjour. It works for every other device in the home that needs a direct connection to manage. Nobody assumes that “http://printer.home” is going to do anything useful; why is the gateway device different?

(I’ve never owned a consumer-grade home gateway; whenever I’ve helped out a neighbour with theirs I’ve always just connected to whatever address the gateway’s DHCP server gave me as a default route. I had no idea there was any expectation that “router.home” would do anything sensible. It does go some way to explain what I saw at L-Root when I last had the opportunity to look, though :-)

Joe

---

From: "John R Levine" <[email-masked]>
Date: 28 Feb 2014 10:43:00 -0500

> (I’ve never owned a consumer-grade home gateway; whenever I’ve helped 
> out a neighbour with theirs I’ve always just connected to whatever 
> address the gateway’s DHCP server gave me as a default route. I had no 
> idea there was any expectation that “router.home” would do anything 
> sensible. It does go some way to explain what I saw at L-Root when I 
> last had the opportunity to look, though :-)

That's OK when the router self-configures, but some do PPPoE and need for 
you to type user ID info.  Most often they currently tell you to go to 
http://192.168.80.1/ but that's going to be a lot less pleasant when 
people start using IPv6 addresses.

I suppose Bonjour is a reasonable way for the router and the PC to fine 
each other, haven't looked at the details.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 28 Feb 2014 11:46:12 -0500

On Fri, Feb 28, 2014 at 10:43:00AM -0500, John R Levine wrote:
> I suppose Bonjour is a reasonable way for the router and the PC to
> fine each other, haven't looked at the details.

This entire discussion sure looks like something that ought to inform
homenet and dnssd, no?

A

-- 
Andrew Sullivan
[email-masked]