Subject: [DNSOP] [[email-masked]: I-D Action: draft-grothoff-iesg-special-use-p2p-names-00.txt]

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 1 Dec 2013 17:48:41 +0100

This draft have originally been copied to the perpass mailing list
(not a working group). As far as I know,
draft-grothoff-iesg-special-use-p2p-names is the first attempt to
actually use RFC 6761 and exercice its procedures. It sees RFC 6761
(section 4) is not crystal-clear about the discussion to have before a
registration. RFC 5226, section 4.1 says "Before approving a request,
the community should be consulted, via a "call for comments" that
provides as much information as is reasonably possible about the
request." so I think a good idea to have dnsop read and discuss about
it.

For the record, I've reviewed
draft-grothoff-iesg-special-use-p2p-names-00, I find it well-written
and clear and I fully support it. Registering these names would be a
very good idea.

Subject: I-D Action: draft-grothoff-iesg-special-use-p2p-names-00.txt
From: [email-masked]
To: [email-masked]
Date: Thu, 14 Nov 2013 04:37:32 -0800
List-Id: Internet Draft Announcements only <i-d-announce.ietf.org>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Intended status: (IESG Approval) Expires: May 17th, 2014
	Author(s)       : Christian Grothoff
                          Matthias Wachs
                          Hellekin O. Wolf
                          Jacob Appelbaum
	Filename        : draft-grothoff-iesg-special-use-p2p-names-00.txt
	Pages           : 9
	Date            : 2013-11-14

Abstract:
   Today, the Domain Name System (DNS) is a key service for the
   Internet.  DNS is primarily used to map human-memorable names to IP
   addresses, which are used for routing but generally not meaningful
   for humans.  However, the hierarchical nature of DNS makes it
   unsuitable for various Peer-to-Peer (P2P) Name Systems.  As
   compatibility with applications using DNS names is desired, these
   overlay networks often define alternative pseudo Top-Level Domains
   (pTLDs) to integrate names from the P2P domain into the DNS
   hierarchy.

   This memo describes common Special-Use Domain Names [RFC6761]
   pseudo Top-Level DNS Names designed to help harden name resolution
   security (e.g., [RFC6840][RFC6975]), provide censorship resistance,
   and protect the users' privacy on the Internet.

   In this IESG Approval document we are asking for domain name
   reservations for five Special-Use Domain Names [RFC6761] TLDs:
   ".gnu", ".zkey", ".onion", ".exit", and ".i2p".

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-grothoff-iesg-special-use-p2p-names-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Ted Lemon <[email-masked]>
Date: Sun, 1 Dec 2013 11:56:43 -0500

> and clear and I fully support it. Registering these names would be a

Why do you support it?   Why is registering these names a good idea?

---

From: Paul Wouters <[email-masked]>
Date: Sun, 1 Dec 2013 12:35:44 -0500 (EST)

> Why do you support it?   Why is registering these names a good idea?

I'm curious too. I'd rather see a generic method instead of an
(incomplete?) list of domain names to reserve. Why wasn't .bofh on
that list? Why was .gnu on that list? What if GNU or someone else
wishes to register .gnu as a new gTLD based on a trademark? Who
are we to disallow that?

This also seems similar to the USENET problem, where John Gilmore
proposed/created the alt.* hierarchy.

It would make more sense to me to reserve something like .alt where
people can plugin onion.alt, gnu.alt, etc, and are guaranteed that
the .alt domain will never actually be delegated by the root. That
means new players who want some peer to peer, no DNS dependancy don't
have to come back here to reserve _their_ names later on.

And once you go that way, one can wonder why not use the already
existing .local for that? Perhaps avoid talking to different protocol
software is a good enough reason not to re-use .local.

But can an RFC even do anything here?  Whether you agree with ICANN
procedures for new gTLDs or not, if I write some software that becomes
popular using a .paul pseudo domain, when does it become valid for me
to request it under RFC 6761? What precedent would tor/gnu/zkey/etc set?
Does IETF even have any say in such matters? Isn't this up to IANA or
ICANN? What about trademarks? What about lawsuits by Gnu Inc or Onion
Corp who want their gTLD?

Other questions I would have is why aren't these people using a
different class from IN? They can have a class of TOR or ONION or GNU?
The traditional reasons for not using any non-IN class is that a lot
of software would not work well with that, but in these cases, the
consumers aren't actually interested in real DNS anyway, and using
a URI that indicates a different class should not be too hard to plug
into existing browsers? A specific tor:// URI plugin would make
more sense to me that sticking with http://sdggjaksgdkgda.onion
construct, especially as at least with tor right now, you are stuck
with the SOCKS API anyway. If tor would be truly transparent and map
to a real ip address handled at the kernel/socket level, then it would
make even more sense to map tor://sdggjaksgdkgda.onion onto a new DNS
class like: sdggjaksgdkgda.onion. IN ONION 1.2.3.4 (or perhaps even a
non-A/AAAA identifier, like a straight public key if that's what the
new socket family would take)

So I think this draft has a lot of issues, technically and legally.

Paul

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 1 Dec 2013 18:42:49 +0100

On Sun, Dec 01, 2013 at 11:56:43AM -0500,
 Ted Lemon <[email-masked]> wrote 

> Why do you support it?   Why is registering these names a good idea?

Good question but you'll have to be patient, the answer will take
time.

A note about IETF procedures, first: RFC 6761 does not say the use of
the "special" domain must be a "good idea". Just that it has to be
documented in a RFC on the standards track *or* approved by IESG.

There are many people who believe that the DNS has some weaknesses:
risks for privacy (see draft-bortzmeyer-dnsop-dns-privacy), and political
risks around the management of the root (the DNS being organized in a
tree, a specific node, the root, has too much power). Some of the
solutions proposed do not change the behavior of the programs and are
therefore out-of-scope for RFC 6761. For instance, the alternative
roots are just a political choice (see RFC 2826) and have zero
technical consequence.

Other solutions have been proposed that are different
technically. Sometimes, they are completely separated from the DNS
(and are out-of-scope for dnsop) and sometimes there is some gateway
with the DNS. My personal opinion is that most of these solutions are
just vague "back of the enveloppe" ideas and will not see any serious
deployment.

On the other hand, there are other proects that are technically
interesting and/or widely deployed. For the cases mentioned in 
draft-grothoff-iesg-special-use-p2p-names:

.onion is used a lot by Tor users, to access "hidden services"
<http://en.wikipedia.org/wiki/Tor_(anonymity_network)#Hidden_services>
It requires special handling (send the name to Tor and not to regular
DNS) and therefore deserves a registration as special.

.gnu and .zkey are used in Gnunet
<http://en.wikipedia.org/wiki/GNUnet>, the first one for
human-readable names and the second-one for cryptographical
names. GNUnet is probably much less used than Tor but is one of the
few serious (proper documentation and "running code") and
comprehensive attempts to reach the objectives of the Vancouver
meeting ("hardening the Internet").

[I let .i2p, I have no strong opinion.]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 1 Dec 2013 18:53:18 +0100

On Sun, Dec 01, 2013 at 12:35:44PM -0500,
 Paul Wouters <[email-masked]> wrote 
 a message of 56 lines which said:

> Why wasn't .bofh on that list?

I don't know it. Where is it documented? Also, RFC 6761 does not say
that you MUST register everything, it only explains what is to be done
if you want to register a name.

> Why was .gnu on that list? 

The GNUnet top-level was named .gads at a time. I do not know the
reasons for the change.

> It would make more sense to me to reserve something like .alt 

This is not the approach chosen by RFC 6761 so I believe you are a
little late.

> the .alt domain will never actually be delegated by the root.

Avoiding a collision with an ICANN domain is not the only rationale
for RFC 6761. The main idea is to have a registry of domains which
require special handling by software (for instance, "do not use DNS,
send to mDNS").

> existing .local for that? 

Because it follows different rules, described in RFC 6762.

> procedures for new gTLDs or not, if I write some software that
> becomes popular using a .paul pseudo domain, when does it become
> valid for me to request it under RFC 6761?

RFC 6761 does not say anything about that. Do note a TLD has already
been registered under RFC 6761, .local. Some people may say that, when
you are a big US company, just hijack the TLD, deploy the software,
and the IETF will ruberstamp you. But if you are just ordinary people
working to improve the Internet, you have no chance of even being
seriously considered.

> What precedent would tor/gnu/zkey/etc set?

Precedent? And .local, what was it?

> Corp who want their gTLD?

RFC 6761 "Hence, the act of defining such a special name creates a
higher-level protocol rule, above ICANN's management of allocable
names on the public Internet." So basically, RFC 6761 says that IETF
has the right to create TLD at will. 

> different class from IN?

You want to resurrect UIT's Net4d long-dead project? Sorry to be
blunt, but this is a bad idea, impossible to deploy.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 1 Dec 2013 13:26:47 -0500

> [I let .i2p, I have no strong opinion.]

These uses are sufficiently different that I think tying them together makes it unlikely that they could get IETF consensus.   And at the moment the IESG is not feeling sufficient urgency to approve the whole laundry list without the individual proposals being more thoroughly specified.

What you have said here does not make me feel additional urgency.

The IESG doesn't have a position on this document at the moment, although we are aware of it and have discussed it, both internally and with the IAB.   I am personally inclined to be an advocate for reasonable proposals for special TLD allocations; indeed, I took it upon myself to take point on this during the most recent IESG formal telechat.   The conversation that ensued has not lead me to believe that other IESG members are feeling an urgent need to do this allocation as an IESG decision.   I think further work is needed before the IESG is likely to take any action on this particular proposal.

What I would like to see is for the individual, unrelated proposals contained in this proposal to be separated out into their own documents.   Then I would like to see the proposals explained in more detail and, as you propose, discussed either here, on dnsext, and/or on some other appropriate mailing list.   It would be nice to see an upswelling of support for these proposals, so that the IESG doesn't have to go it alone (because we most likely won't).

BTW, what I am saying here is based on my own assessment of conversations that have occurred in the IESG and with the IAB, but neither the IESG nor the IAB has stated any clear position on this in my causal domain, so what I've said here is strictly my (somewhat informed) opinion, not a statement from the IESG or the IAB.

---

From: "Marco Davids (SIDN)" <[email-masked]>
Date: Mon, 2 Dec 2013 10:56:14 +0100

> and clear and I fully support it. Registering these names would be a

Would it be worthwhile to add .bit to the list (Namecoin)?

--
Marco

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 2 Dec 2013 10:58:34 +0100

> Would it be worthwhile to add .bit to the list (Namecoin)?

I suggest .bit be a different draft as .bit compared to the other names actually do use the DNS protocol for resolution. Note that I am not against .bit, but just want it separate as the argument for it being reserved is different.

   Patrik

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 2 Dec 2013 10:16:51 -0500

> the .alt domain will never actually be delegated by the root. 

And, behold, we have .arpa already.  We could just create anything we
wanted under there.  I don't get why some new TLD is needed.

> software is a good enough reason not to re-use .local.

Certainly do not re-use .local for this.  The reason mDNS needed a
different TLD is (to drastically oversimplify) because it uses the TLD
as a protocol-shift token: when you're in .local, you're actually
using a different protocol, and this is a way to keep the otherwise
parallel name-space aligned.  (This is the fourth extension mechanism
we have in the DNS: we have RRTYPEs, CLASSes, underscore labels, and
TLDs.  Hurray!)

> into existing browsers? 

The last such proposal was a mechanism to use a new CLASS for IDN
support.  It turned out it wouldn't work because (among other reasons)
there were too many resolvers that spit up on any CLASS other than IN.
I am dubious that has improved, though I'd be prepared for evidence
that it had.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 2 Dec 2013 16:24:12 +0100

> wanted under there.  I don't get why some new TLD is needed.

There are two issues here with the TLDs:

1. How to handle things technically "the best way"

2. Already deployed "things"

It is also the case that for some "things" the fact is that the actual resolution mechanism is not using the DNS at all, so the string to "match" must then be "foobar.arpa" or equivalent for whatever TLD is chosen to decide to use some non-DNS resolution mechanism for the string "foobar".

I am trying to wrap my own brain around this and what I think the best solution is...and do not have any really good solutions to suggest.

   paf

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 2 Dec 2013 07:38:17 -0800

> I am dubious that has improved, though I'd be prepared for evidence

SLDs under .arpa are cheap and easily managed by the IETF. Forcing someone into a different class (where all sorts of things could block by accident) seems silly.

--Paul Hoffman

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 2 Dec 2013 10:40:18 -0500

> and clear and I fully support it. Registering these names would be a

I reviewed this document 

I have a big conceptual problem with it, 
Why do people think that different namespaces should be identified by a postfix? 

In DNS wire protocol we have classes, to me that seems like much better way of handling this. 
I even will question why are the not using  something more expressive like 
	GNU#&#<domain_name> 

#@# is in this case a random string to separate namespaces 

I'm not sure the same resolution library should be used for different namespaces that are distributed hash tables. 

TLD live on the boundary of IETF and ICANN, we do not want to push that boundary but allowing RFC to allocate what ICANN charges big bucks for.

	Olafur

> Resent-From: Stephane Bortzmeyer <[email-masked]>
> Date: November 14, 2013 7:37:32 AM EST
> Resent-To: [email-masked]
> Reply-To: [email-masked]
> 
> 
> 
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Warren Kumari <[email-masked]>
Date: Mon, 2 Dec 2013 10:50:35 -0500

> Would it be worthwhile to add .bit to the list (Namecoin)?

And I would like .pony as well please.

The concern that we run into is deciding where to draw the line -- can I just start using .wkumari in some random namespace and ask for it to be reserved?

Either these are "real" DNS names and should follow the "normal" DNS process (whether or not we like that process), or they are not, and don't really belong in the DNS.
I get that there are some "special cases" -- would it be feasible to reserve *one* name (.p2p? .namespace?) and have things like this migrate over time under names within that? (.gnu.namespace)? Or simply move these under some existing namespace.

W

-- 
No man is an island, But if you take a bunch of dead guys and tie them together, they make a pretty good raft.
                --Anon.

---

From: Joe Abley <[email-masked]>
Date: Mon, 2 Dec 2013 11:00:30 -0500

On Monday 2 December 2013 at 10:38, Paul Hoffman wrote:

> SLDs under .arpa are cheap and easily managed by the IETF.

Yes.
> Forcing someone into a different class (where all sorts of things could block by accident) seems silly.
I don't know that anybody is talking about force. I'm not sure what that would look like, in fact, given that anybody is free to write software that does whatever they think is sensible.

But discarding the option of using a different class at an over-general high level seems silly, too. Don't the operational considerations depend on the details?

Saying that using a non-IN class is a non-starter seems about as silly as saying that using a non-IN class is always the right thing.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Mon, 2 Dec 2013 11:17:18 -0500

> wanted under there.  I don't get why some new TLD is needed.

I wrote the following in a more private setting, but I will reiterate it here, in hopes that if what I am saying is completely idiotic someone will do me the courtesy of pointing out why:

RFC 6761 has IETF consensus, and does not propose adding new namespaces under .arpa, but rather at the top level.   Here's what RFC3172 says on the topic of .arpa:

  This domain is termed an "infrastructure domain", as its role is to
  support the operating infrastructure of the Internet.  In particular,
  the "arpa" domain is not to be used in the same manner (e.g., for
  naming hosts) as other generic Top Level Domains are commonly used.

Aside from the purely practical matter that having special domains live under .arpa would be more complicated to implement, it doesn't make sense. Consider .local—our main example of a special-use domain.   Would it make sense for .local to be under .arpa?   I don't think so.   .local is specifically not "internet infrastructure."   It isn't even DNS.   It's an escape from the DNS namespace, with different semantics than domain names in the DNS.

The other proposed special uses are similar.   Putting them under .arpa might be _expedient_, because it avoids the whole change control question, but that's pretty much the only way I can think of that it makes sense.

---

From: Joe Abley <[email-masked]>
Date: Mon, 2 Dec 2013 11:29:36 -0500

> naming hosts) as other generic Top Level Domains are commonly used.

Perhaps 3172 needs to be updated to reflect current IAB practice, then. It's not hard to find examples of names under ARPA which contradict the text you quoted (e.g. see RFC 5855).
> Aside from the purely practical matter that having special domains live under .arpa would be more complicated to implement,

This feels like an over-general pronouncement that can't hope to be accurate in all cases. Why is it more complicated in the general case? More complicated than what?
> it doesn't make sense. Consider .local—our main example of a special-use domain. Would it make sense for .local to be under .arpa? I don't think so. .local is specifically not "internet infrastructure." It isn't even DNS. It's an escape from the DNS namespace, with different semantics than domain names in the DNS.

I think you're sharing personal opinion rather than citing fact ("make sense"). The .local convention happened to be adopted by Apple for use in a DNS-like protocol, and was documented (and the IN-class top-level label reserved) later. They could equally well have adopted .local.arpa or .local.apple.com.

I'm not complaining about Apple's innovation here, or their decision to document it at the IETF. But I don't think it's sufficient to assert that alternatives would not have made sense without justifying why that is so.
> The other proposed special uses are similar. Putting them under .arpa might be _expedient_, because it avoids the whole change control question, but that's pretty much the only way I can think of t…

It doesn't avoid the whole change control question -- it just reduces the change control to one with a single, uncontentious decision point (the IAB). By contrast, the business of identifying reserved strings (and enforcing their non-delegation for other purposes) in the root zone is fraught with administrative ambiguity.

Joe

---

From: Andreas Gustafsson <[email-masked]>
Date: Mon, 2 Dec 2013 18:53:57 +0200

Andrew Sullivan wrote:
> wanted under there.

We could do that.  There is also an even simpler solution: the
developers of p2p applications could simply register the domains they
are going to special-case the same way you would register any other
domain.

For example, instead of asking IETF to reserve .exit, the Tor project
could simply reserve the exit.torproject.org subdomain of their
existing torproject.org domain for that purpose, or they could
register torexit.net, or if they want .exit really badly, they can 
pay ICANN the same application fee any other gTLD applicant would.
-- 
Andreas Gustafsson, [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Mon, 2 Dec 2013 12:44:48 -0500

> Perhaps 3172 needs to be updated to reflect current IAB practice, then. It's not hard to find examples of names under ARPA which contradict the text you quoted (e.g. see RFC 5855).

This seems like a non-sequitur, since RFC 5855 refers to a function that RFC 3172 specifically mentions.

> This feels like an over-general pronouncement that can't hope to be accurate in all cases. Why is it more complicated in the general case? More complicated than what?

If special-use names are at the top, then you can just look at the terminal label to see that you need to use a different protocol to resolve names under the special-use name.   If special-use names are not at the top, then you have to have special code that grovels through the labels doing pattern matches.   This is clearly more code; you can argue that it's not much more code, but I think there's a reason why apple chose not to use local.apple.com, for example.

Aside from the additional implementation complexity, putting these domains under some other TLD makes them longer to type.   In the case of domains that are not intended to be typed, this isn't a problem, of course.

> I think you're sharing personal opinion rather than citing fact ("make sense"). The .local convention happened to be adopted by Apple for use in a DNS-like protocol, and was documented (and the IN-…

So, in what sense is MDNS "internet infrastrucure?"

> I'm not complaining about Apple's innovation here, or their decision to document it at the IETF. But I don't think it's sufficient to assert that alternatives would not have made sense without just…

No argument here, but I thought that's what I was doing.

> It doesn't avoid the whole change control question -- it just reduces the change control to one with a single, uncontentious decision point (the IAB). By contrast, the business of identifying reser…

It's not at all clear to me that this is an issue, and if it is, we should figure that out.   I would like to think that ICANN understands that there is a change control conflict here, and is willing to work with us to make sure that we don't step on each other's toes.   Clearly it's incumbent upon the IETF not to be frivolous in the use of RFC 6761.   But I have not heard from anyone that the IETF should not ever use RFC 6761, and that seems to be the position you are advocating at the moment.

---

From: Joe Abley <[email-masked]>
Date: Mon, 2 Dec 2013 12:58:42 -0500

On Monday 2 December 2013 at 12:44, Ted Lemon wrote:

> On Dec 2, 2013, at 11:29 AM, Joe Abley <[email-masked] (mailto:[email-masked])> wrote:

I was perhaps being a little opaque; RFC 5855 specifies names under .ARPA for hosts (A.IN-ADDR-SERVERS.ARPA, etc.) This seems to be in contradiction to the text you quoted.
> If special-use names are at the top, then you can just look at the terminal label to see that you need to use a different protocol to resolve names under the special-use name.

Oh, I see what you mean now, thanks. I don't necessarily agree that it's significantly easier to check the final label (e.g. ".local") than the final several labels (e.g. ".local.apple.com") but I understand your point.
> > I think you're sharing personal opinion rather than citing fact ("make sense"). The .local convention happened to be adopted by Apple for use in a DNS-like protocol, and was documented (and the IN-class top-level label reserved) later. They could equally well have adopted .local.arpa or .local.apple.com (http://local.apple.com).
> 

It's a protocol that is used on the Internet. It's a protocol that is used to locate and obtain addresses for hosts connected to the Internet. I appreciate that it has a restricted scope, but in practical terms so does everything.
> It's not at all clear to me that this is an issue, and if it is, we should figure that out.

I don't disagree. It's not clear to me either; I'm just conscious of the fact that perspectives can vary depending on whether you're used to looking at things from an IETF perspective or an ICANN perspective. I have been somewhat familiar with both, and I'm confused. :-)
> I would like to think that ICANN understands that there is a change control conflict here, and is willing to work with us to make sure that we don't step on each other's toes. Clearly it's incumbent upon the IETF not to be frivolous in the use of RFC 6761. But I have not heard from anyone that the IETF should not ever use RFC 6761, and that seems to be the position you are advocating at the moment.

I can see how I might have given that impression, but it wasn't intentional. 

I have some personal dissatisfaction with the approach taken in 6761 (I think there was an opportunity to unify a range of technical policy and collapse a number of registries that give the appearance of doing the same thing in different places, and I think its a shame that the opportunity was not taken) but I have no objection in principle to the idea that some right-most labels could/should be reserved for use by the IETF.

The reason my knee is jerking is that I think in general it's a mistake to assume that a unique top-level label is the only practical recourse for protocol designers looking for stable, dedicated namespaces. There are lots of other options, several of which mentioned in this thread, and one size does not fit all.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Mon, 2 Dec 2013 13:13:03 -0500

> I was perhaps being a little opaque; RFC 5855 specifies names under .ARPA for hosts (A.IN-ADDR-SERVERS.ARPA, etc.) This seems to be in contradiction to the text you quoted.

Hm, okay, but that seems more like infrastructure than it does like a name.   Every domain name is a name in that sense.

> It's a protocol that is used on the Internet. It's a protocol that is used to locate and obtain addresses for hosts connected to the Internet. I appreciate that it has a restricted scope, but in pr…

Right, but a protocol is not infrastructure.   The name servers that serve IN-ADDR.ARPA are infrastructure.   IN-ADDR.ARPA is infrastructure.   MDNS is a protocol for discovering hosts on the local wire.   It isn't "internet" and it isn't "infrastructure"—it exists to deal with a lack of infrastructure.

> I don't disagree. It's not clear to me either; I'm just conscious of the fact that perspectives can vary depending on whether you're used to looking at things from an IETF perspective or an ICANN p…

Whereas I know almost nothing of the ICANN perspective, so I feel like I am navigating a maze in the dark!

> The reason my knee is jerking is that I think in general it's a mistake to assume that a unique top-level label is the only practical recourse for protocol designers looking for stable, dedicated n…

I think that's a valid point.  However, the proposal has been made to register some existing uses of special-use TLDs, so it's not the case that we are dealing with a blank sheet of paper here.   The number of special-use domains being discussed is fairly small, and they are names that likely would not see heavy conflict with proposed ICANN uses of TLDs.

So given that RFC 6761 does in fact represent IETF consensus at the moment, I think it's reasonable to consider allocating these names.   If ICANN comes back and says "we really don't think you should do this because of X," I think we ought to take that seriously.

But we are not there now, and I don't know that we will get there.   So I don't think it's a particularly useful point to raise in terms of _the IETF's_ consideration of this proposal.

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 2 Dec 2013 19:14:49 +0100

> Why do people think that different namespaces should be identified by a postfix? 

The people that use browsers...that "just" type in something that looks like, smells like, and acts like a domain name... :-P

Although DNS protocol is not in use for the name resolution, but HTTP is used for the actual protocol to fetch whatever data is to be fetched.

> I'm not sure the same resolution library should be used for different namespaces that are distributed hash tables. 

Agree, but...

> TLD live on the boundary of IETF and ICANN, we do not want to push that boundary but allowing RFC to allocate what ICANN charges big bucks for.

Correct, and that is why I think:

1. It is important to have this discussion

2. We should have different proposals for .bit (and similar) and other hash tables

   Patrik

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 2 Dec 2013 13:32:34 -0500

On Mon, Dec 02, 2013 at 12:44:48PM -0500, Ted Lemon wrote:
> 
> If special-use names are at the top, then you can just look at the terminal label to see that you need to use a different protocol to resolve names under the special-use name.  If special-use names are not at the top, then you have to have special code that grovels through the labels doing pattern matches. 

This is a bizarre argument.  Once you're using DNS names, you need code that handles names label by label anyway (and copes with all the brain-death from the search path and the difference between FQDN-in-URI vs. FQDN-in-DNS and all that).  So you're going to have to cope with the label-by-label rules, and at that point I find it hard to believe that the number of labels makes a really big difference to complexity.  

If your argument is instead that implementers are just going to pop off the last label and look at it, well, then they need some namespace other than the DNS anyway, because that's not how the DNS works.  Assuming that you can just pop the right-most label off some putative domain name and assess that without going through all the DNS matching rules, in fact, strikes me as dangerous.  And once you've shifted into .arpa. space, at least you know you're supposed to be dealing with infrastructure.

Also, partly echoing what Joe argued, the .local case is special because (1) Apple implemented and released it first and then documented; (2) the original plan was to treat those names as part of the same port-53 protocol with locally-scoped semantics; (3) then the plan became to run a perfectly parallel namespace for another protocol; and (4) in any case, the idea was to hide from the user that the names were in some way different.  (We can see the nasty side effects of 2-4 in the current discussions in DNSSD, by the way.)  It does not appear in this case, at least as near as I can tell from my admittedly less-than-careful read so far, that the plan is to be quite so similar to DNS, so I'm actually not sure that what's needed here is the DNS at all.  I'm in fact reminded of a widely-worn t-shirt[1].

I think this conversation is useful, but I really think it's premature to be talking about TLDs.

[1] http://www.cafepress.com/nxdomain.624728706

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Joe Abley <[email-masked]>
Date: Mon, 2 Dec 2013 13:37:30 -0500

On Monday 2 December 2013 at 13:13, Ted Lemon wrote:
> On Dec 2, 2013, at 12:58 PM, Joe Abley <[email-masked] (mailto:[email-masked])> wrote:

Perhaps I'm being over-pedantic, but the 3172 text refers to "naming hosts" and "host names" have specific meaning that do not apply to every domain name.

I suspect the answer is that 3172 is a little vague in its direction here, and arguably opaque about the motivations for that direction. This makes 3172 a poor choice for justification of use (or not) of names under ARPA, I think; better to reduce its impact to "IAB approval required" and not second-guess what the IAB might think.
> Right, but a protocol is not infrastructure. The name servers that serve IN-ADDR.ARPA are infrastructure. IN-ADDR.ARPA is infrastructure. MDNS is a protocol for discovering hosts on the local wire.…

... by providing infrastructure? :-)
  
> But we are not there now, and I don't know that we will get there. So I don't think it's a particularly useful point to raise in terms of _the IETF's_ consideration of this proposal.  
I think this approach seems sane and good.

Joe

---

From: SM <[email-masked]>
Date: Tue, 03 Dec 2013 08:05:43 -0800

Hi Stephane,
>working to improve the Internet, you have no chance of even being

Rubberstamping is only possible when people remain quiet.  The easier 
path is to fix the proposal so that it looks like a technical specification.

>Precedent? And .local, what was it?

I asked about .local (see 
http://www6.ietf.org/mail-archive/web/ietf/current/msg65346.html 
).  I did not receive any reponse.

Please note that .local has some history.  I would look at it as "do 
not use that string as it is unlikely that uniqueness can be ensured".

>has the right to create TLD at will.

The IETF should have a good explanation for doing that.  In my 
opinion the draft under discussion does not provide a good explanation.

At 07:40 02-12-2013, Olafur Gudmundsson wrote:
>TLD live on the boundary of IETF and ICANN, we do not want to push 
>that boundary but allowing RFC to allocate what ICANN charges big bucks for.

I agree with Olafur that it is not a good idea to push the boundary.

Regards,
-sm

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 3 Dec 2013 18:08:25 +0100

On Mon, Dec 02, 2013 at 11:00:30AM -0500,
 Joe Abley <[email-masked]> wrote 
 a message of 20 lines which said:

> Saying that using a non-IN class is a non-starter seems about as
> silly 

There have been an ITU project to use classes (UN instead of IN?) to
have different namespaces, probably to have the new spaces managed by
the ITU. The project was named Net4d (Web site seems down now).

AFAIK, the project did not even attempt to actually test (at least in
in the lab) that it was feasible to use other classes. Knowing what
we know about the ossification of the Internet and the DNS, there are
very good reasons to be pessimistic.

If we want actual testing of the ability to run non-IN classes, I
accept donations in bitcoins to do so in my lab :-) But, anyway, you
have very little chance of convincing any developer to spend time in
this direction, which is clearly dead.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 3 Dec 2013 18:10:31 +0100

On Mon, Dec 02, 2013 at 01:32:34PM -0500,
 Andrew Sullivan <[email-masked]> wrote 
 a message of 25 lines which said:

> Also, partly echoing what Joe argued, the .local case is special
> because (1) Apple implemented and released it first and then
> documented;

Exactly the same situation with .onion. The Tor people implemented it
a long time ago and released it. 

> so I'm actually not sure that what's needed here is the DNS at all. 

Indeed, .onion, .zkey and .gnu do not use the DNS at all. They need
domain names but not the DNS. Hence the proposal to register them as
special domain names.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 3 Dec 2013 18:11:25 +0100

On Mon, Dec 02, 2013 at 06:53:57PM +0200,
 Andreas Gustafsson <[email-masked]> wrote 
 a message of 20 lines which said:

> if they want .exit really badly, they can pay ICANN the same
> application fee any other gTLD applicant would.

Did Apple pay ICANN for .local? No. Why would Tor people have to do
it?

---

From: joel jaeggli <[email-masked]>
Date: Tue, 03 Dec 2013 09:13:17 -0800

> very good reasons to be pessimistic.

using a new class for a greenfield seems somewhat different then
expecting it to work across the population of internet resolvers that
are already deployed.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 3 Dec 2013 18:13:29 +0100

On Mon, Dec 02, 2013 at 10:56:14AM +0100,
 Marco Davids (SIDN) <[email-masked]> wrote 

> Would it be worthwhile to add .bit to the list (Namecoin)?

The way I understand RFC 6761, it does not say we must register
proactively every TLD which is floating around. It just provides an
_opt-in_ way for people who _want_ to register special TLD to do so.

So, if the .bit people want this name registered, fine with me. But
they will have to document the proposal and push it to the IESG like
the .onion or .zkey people did.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 3 Dec 2013 18:16:00 +0100

On Mon, Dec 02, 2013 at 10:50:35AM -0500,
 Warren Kumari <[email-masked]> wrote 
 a message of 88 lines which said:

> The concern that we run into is deciding where to draw the line --
> can I just start using .wkumari in some random namespace and ask for
> it to be reserved?

Apple did it for .local, you're welcome to do the same. RFC 6761 do
not seem to describe criterias for accepting/rejecting special TLD
registrations. If one were to ask, for instance, proofs of actual
deployment, .onion would provide them easily and .pony could not.

> Either these are "real" DNS names and should follow the "normal" DNS
> process (whether or not we like that process), or they are not, and
> don't really belong in the DNS.

Noone talked about the DNS. Like the mDNS of .local, they are
different protocols and that's why they require special TLD.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Dec 2013 12:27:09 -0500

> this direction, which is clearly dead.

Furthermore, it doesn't even address the problem, because the problem we are talking about is a naming problem, not a problem that exists within the DNS protocol.  So by definition you can't solve it with classes, because classes are a DNS thing.

---

From: David Conrad <[email-masked]>
Date: Tue, 3 Dec 2013 11:00:04 -0800

> Furthermore, it doesn't even address the problem, because the problem we are talking about is a naming problem, not a problem that exists within the DNS protocol.  So by definition you can't solve…

If it isn't a DNS thing, then why is there a discussion of the allocation of top-level _domains_?  If these applications aren't making use of the DNS, then why does anyone care if they use something that looks like a domain name?

The issue here is that they are, in fact, using the DNS in the sense that they are using applications that expect to query a local DNS stub resolver and they are (presumably) expecting that resolver to distinguish between a query for a "regular" domain name and one of these non-DNS "domain names". The reason they can't use classes is because there isn't a convenient mechanism to specify an alternative class using the vast majority of applications, hence a fallback to distinguishing using "special" names.

I have significant concerns that this is not going to scale. There needs to be a better discriminator than simply "because I wrote an RFC that describes a protocol that assumes a top-level domain".

Regards,
-drc

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 3 Dec 2013 14:05:43 -0500

On Tue, Dec 03, 2013 at 06:10:31PM +0100, Stephane Bortzmeyer wrote:
> domain names but not the DNS.

Nonsense.  The very abstract says, "[C]ompatibility with applications
using DNS names is desired…."  The hard lesson of mDNS and all these
other semi-successful attempts to glue into DNS space without tripping
over all the same old DNS limitations is that, once you offer people
domain names, you convince them they have a name that they can use in
a protocol slot, and they will.

It's clear to me, however, that I'm going to have to read the
referenced documents more closely.  I have a sneaking suspicion that
the names actually _aren't_ like DNS names in some ways, and that they
won't work if they're used in DNS protocol slots.  But if the goal
really is to reserve the namespace and _never_ have DNS for these
things, then the special handling in
draft-grothoff-iesg-special-use-p2p-names-00 is wrong.  It ought
instead to be a mirror of the handling of .invalid in RFC6761.  I'd be
way less concerned about proceeding with these registrations if that
were the goal.  Nobody can reasonably object to avoiding colliding
namespaces, given what's already going on with the "name collision"
work in this round of TLD expansion.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 3 Dec 2013 23:10:06 +0100

On Tue, Dec 03, 2013 at 11:00:04AM -0800,
 David Conrad <[email-masked]> wrote 
 a message of 79 lines which said:

> If it isn't a DNS thing, then why is there a discussion of the
> allocation of top-level _domains_?  

Because domain names and DNS are two different things. Domain names is
a syntax and rules for registration. DNS is a protocol to find data
from domain names. Domain names can be resolved with other protocols:
HOSTS.TXT, LDAP, new-and-shiny-DHT, and many others.

> If these applications aren't making use of the DNS, then why does
> anyone care if they use something that looks like a domain name?

It does not look like a domain name, it is a domain
name. suw74isz7wqzpmgu.onion is a domain name, just like virtualized.org.

> The issue here is that they are, in fact, using the DNS in the sense
> that they are using applications that expect to query a local DNS
> stub resolver 

No, no, no. Few applications query " a local DNS stub resolver" (dig
is an exception). Most applications query a local name resolution
service, through a library routine such as getaddrinfo. Unknown to the
application, this name resolution service contracts to various
resolution protocols, defined by the programmer and sometimes by the
system administrator.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 3 Dec 2013 23:11:15 +0100

On Tue, Dec 03, 2013 at 02:05:43PM -0500,
 Andrew Sullivan <[email-masked]> wrote 
 a message of 27 lines which said:

> Nonsense. 

I disagree.

> The very abstract says, "[C]ompatibility with applications using DNS
> names is desired…."

Bad wording in the draft, indeed, it should have been "domain names".

---

From: SM <[email-masked]>
Date: Tue, 03 Dec 2013 14:38:39 -0800

Hi Jacob,
At 08:52 03-12-2013, Jacob Appelbaum wrote:
>In terms of informational RFCs, I think it is clearly a good idea to
>document what is realistically in use.

Yes.

>I assume that .local did not always have history? However, I think that
>there are clearly many p2p systems with a history as well - .onion is
>nearly ten years old now.

I was referring to the history within the IETF.  The (draft) proposal 
took over ten years to be published.

>What would make it a good explanation?

I'll read the draft again and comment.  Seriously, it is difficult to 
tell what would be a good explanation.  I would describe it as "the 
person has thought about the issues and can provide good answers for them".

>What is a better alternatively? Shall we ignore the IETF and ICANN
>entirely? Shall we give up on IETF and shell out the cash to ICANN?

It is premature to give up on getting the draft published by the 
IETF.  I would answer "no" to the second question. :-)

>The P2P systems push the boundary - the informational RFC merely
>documents it and ensures that the IETF is the best place to find that
>information.

I'd say put the process discussion on hold, focus on the technical 
content; then discuss the draft within the IETF.

Regards,
-sm

---

From: David Conrad <[email-masked]>
Date: Tue, 3 Dec 2013 16:50:37 -0800

Stephane,

On Dec 3, 2013, at 2:10 PM, Stephane Bortzmeyer <[email-masked]> wrote:
> service, through a library routine such as getaddrinfo.

Yes. Mea culpa. As I've already explained a couple of times in private email (wow, people actually read my email??), I actually meant "local stub resolver" (no DNS) and:

"My point was exactly that the local stub resolver (that is, the library on the system that issues to name resolution requests, not the part of the name resolution system that does the work, be it DNS, mDNS, YP, or whatever) will be expected to distinguish between real DNS names and these pseudo-DNS names. This implies every time the IETF makes use of 6761, those tables of special labels is going to need to be updated (and I suspect the chances of this being done universally and consistently approach zero). This means an application that will work on one system (that has update the table) won't work on another (because the table hasn't been updated). I consider this sub-optimal."

Haven't we been here before (e.g., .bitnet/.csnet/.uucp)?

Ignoring that, other than aesthetics, what is the downside of <p2p>.alt or <p2p>.not-dns or <p2p>.arpa again?

Regards,
-drc

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 4 Dec 2013 04:41:27 +0100

> Ignoring that, other than aesthetics, what is the downside of <p2p>.alt or <p2p>.not-dns or <p2p>.arpa again?

Not much but it is hard to exclude the aesthetics and issues for deployed software. Same question as for .local, part from of course that <p2p>.arpa would of course first give a referral back IF the DNS is queried for the domain name.

   Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 4 Dec 2013 04:46:46 +0100

Btw, I did ask a person working with these things how this is implemented in reality, out in the world, and the following is the response:

> *** At this point I don't think there's a global plugin for all of
> them. The Tails distribution has a nice page explaining how to enforce
> Tor (and I2P) that covers DNS resolution hijacking, HTTP proxying, and
> IP redirection of 127.192.0.0/10 to ensure all traffic not destined to
> clear Internet goes through Tor and I2P.
> 
> https://tails.boum.org/contribute/design/Tor_enforcement/
> 
> Assuming you have Tor and I2P running, you could declare an HTTP and
> SOCKS proxy on localhost--e.g. using Privoxy, and then configure
> Privoxy to route .i2p to the local I2P resolver (localhost:8887), and
> .onion to the Tor resolver (localhost:9050)
> 
> It works similarly for .bit (Namecoin) or the GNS, but the preferred
> method is via the Name Service Switch because those can and do provide
> different RR types that are not available with the DNS RR types. E.g.,
> for GNUnet you would do:
> 
> # grep hosts /etc/nsswitch.conf
> hosts: files gns [NOTFOUND=return] dns
> 
> You might also need to remove the reverse path filtering on your
> virtual gnunet-dns interface:
> 
> # echo 0 > /proc/sys/net/ipv4/conf/gnunet-dns/rp_filter
> 
> Tor's trac also have an extensive page on DNS resolution alternatives
> and their configuration:
> 
> https://trac.torproject.org/projects/tor/wiki/doc/DnsResolver
> 
> Hope that helps,

   Patrik

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 4 Dec 2013 10:44:49 +0100

On Tue, Dec 03, 2013 at 04:50:37PM -0800,
 David Conrad <[email-masked]> wrote 
 a message of 63 lines which said:

> This implies every time the IETF makes use of 6761, those tables of
> special labels is going to need to be updated (and I suspect the
> chances of this being done universally and consistently approach
> zero). 

It seems a criticism of RFC 6761, not of the current registration
proposal. If this is so, I would say you are a bit late, 6761 is
already published.

> Ignoring that, other than aesthetics, what is the downside of
> <p2p>.alt or <p2p>.not-dns or <p2p>.arpa again?

My main concern will be that it won't be easier or faster to get a
<p2p>.arpa and we'll see exactly the same discussions.

---

From: Tony Finch <[email-masked]>
Date: Wed, 4 Dec 2013 12:36:08 +0000

David Conrad <[email-masked]> wrote:
>
> "My point was exactly that the local stub resolver (that is, the library
> on the system that issues to name resolution requests, not the part of
> the name resolution system that does the work, be it DNS, mDNS, YP, or
> whatever) will be expected to distinguish between real DNS names and
> these pseudo-DNS names. This implies every time the IETF makes use of
> 6761, those tables of special labels is going to need to be updated (and
> I suspect the chances of this being done universally and consistently
> approach zero). This means an application that will work on one system
> (that has update the table) won't work on another (because the table
> hasn't been updated). I consider this sub-optimal."
>

To me this sounds a lot like private namespaces in the DNS which
correspond to private networks - the analogy being that these special
non-DNS names often correspond to special overlay networks (as in Tor and
GNUnet).

So you need to have the p2p software in order to use the overlay network
and to resolve the names. If your system doesn't know about the
specialness of the name then it won't resolve properly but you would not
be able to use it if it did resolve properly.

If an application needs the special connectivity, then it needs to require
the special support software.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: David Conrad <[email-masked]>
Date: Wed, 4 Dec 2013 08:37:28 -0800

Tony,

> non-DNS names often correspond to special overlay networks (as in Tor and

Yes, except they aren't really private -- they're public but only if you know/have installed the right magic bits.

> be able to use it if it did resolve properly.

Yes. And, of course, "won't resolve properly" most likely means sending a query to the root and getting back an NXDOMAIN. Last I checked, the "L" root server is getting about 2000 queries per second for ".local" (about 7 Mbps in DNSSEC signed outbound traffic if my math is right). To be honest, given the crap that hits the roots these days, I'm not sure this matters all that much but it probably should be a consideration.

> the special support software.

My concern is that given the names in question look like domain names, particularly now in the days of new gTLDs, even though they aren't _really_ domain names (in the sense that they can't be looked up in the domain name system), they'll be treated like domain names leading to confusion/interoperability problems. If I send my Pointed Haired Boss a note referencing pictures of him with farm animals on photos.onion, he may try to click/cut-paste that "domain name" in a browser. If he doesn't have the .onion overlay software installed and configured, he's likely to be disappointed/confused/angry (at least with .local if my PHB is an English speaker, he might have a hint). The DNS community spent a lot of time back in the days of alternate root proposals arguing this sort of confusion would be a bad thing. I figure it's still bad.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Wed, 4 Dec 2013 09:14:10 -0800

Stephane,

On Dec 4, 2013, at 1:44 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> It seems a criticism of RFC 6761, not of the current registration proposal. 

Yes and no.  Yes, I think 6761 is broken in parts (somehow I missed discussion of the draft), however the issue I'm worried about is the proliferation of the pseudo-domains and the confusion/noise I'm worried they'll cause.

> <p2p>.arpa and we'll see exactly the same discussions.

On the plus side, I suspect there would be less of an assumption that <p2p>.arpa is a regular domain name.

On the minus side, management of .ARPA is a part of the IANA functions contract which implies changes will require US DoC NTIA approval, so I'd agree that there is a potential for delays and ... non-technical discussion.

But how about .alt or .not-dns (or as has been suggested .p2p)?

Regards,
-drc

---

From: Warren Kumari <[email-masked]>
Date: Wed, 4 Dec 2013 14:40:36 -0500

> But how about .alt or .not-dns (or as has been suggested .p2p)?

I really like .alt -- it makes it clear that this is an alternate namespace type thing, mirrors the usenet alt convention, etc.
.p2p seems less descriptive, and not all alternate things are peer to peer.

Whatever the case, .<new label> could be delegated to AS112 -- if you don't have the special source that uses the alternate namespace this will at least cut down on the excess "junk" queries hitting the root.

W

-- 
Eagles soar but a weasel will never get sucked into a jet engine

---

From: Joe Abley <[email-masked]>
Date: Wed, 4 Dec 2013 14:59:59 -0500

> .p2p seems less descriptive, and not all alternate things are peer to peer.

I think it's pertinent to characterise what you mean by .alt (or .whatever). Do you mean adding .alt to the reserved list so that it is not used? Or do you mean it should be delegated somewhere? If so, that can of worms will need to be opened at some point, and pandora's box of root zone management needs to be opened.
> Whatever the case, .<new label> could be delegated to AS112 -- if you don't have the special source that uses the alternate namespace this will at least cut down on the excess "junk" queries hittin…

See above regarding the Box, but also bear in mind that we're moving AS112 towards DNAME redirection rather than delegation.

There was at least one study commissioned by ICANN on the prudence of provisioning DNAME RRs in the root zone that concluded that there was no obvious danger, but remember that any novel RRTypes in the root zone are going to need implementation time in the systems and processes involved in root zone management, and such changes have proven in the past to be neither quick nor easy.

There are also many non-technical communities that have demonstrated the effectiveness of their brakes when it comes to making changes to root zone provisioning, no matter how benign the change might seem to a technical audience.

Note that I'm not commenting on any general or specific idea, just pointing out that there are dragons every which way you look if your proposal involves the root zone.

Joe

---

From: SM <[email-masked]>
Date: Wed, 04 Dec 2013 12:01:47 -0800

Hi David,
At 09:14 04-12-2013, David Conrad wrote:
>On the minus side, management of .ARPA is a part of the IANA 
>functions contract which implies changes will require US DoC NTIA 
>approval, so I'd agree that there is a potential for delays and ... 
>non-technical discussion.

.arpa is an IETF matter.

Regards,
-sm

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 4 Dec 2013 12:46:36 -0800

>> On the minus side, management of .ARPA is a part of the IANA functions contract which implies changes will require US DoC NTIA approval, so I'd agree that there is a potential for delays and ... n…

It is clearly stated in RFC 3172 that it is administered by the IAB, not the IETF, and that the delegations happen through IANA.

--Paul Hoffman

---

From: Joe Abley <[email-masked]>
Date: Wed, 4 Dec 2013 15:53:06 -0500

> > non-technical discussion.

Per RFC 3172, changes to the ARPA zone are authorised by the IAB.

Per the most recently-awarded IANA Functions Contract, changes to the ARPA zone are not authorised by NTIA. They use a similar workflow to that employed for root zone management, but not identical.

Joe

---

From: David Conrad <[email-masked]>
Date: Wed, 4 Dec 2013 13:25:57 -0800

> Per the most recently-awarded IANA Functions Contract, changes to the ARPA zone are not authorised by NTIA. They use a similar workflow to that employed for root zone management, but not identical.

In the past, additions to .ARPA (as approved by the IAB in accordance with RFC 3172) definitely did require NTIA authorization before they could be placed into the zone.  I'm glad to hear that this has been clarified and that NTIA authorization is no longer required.

I personally wouldn't find dumping the decision about whether to add a non-DNS pseudo-domain into the "hostname namespace" into the laps of the IAB objectionable (not being on the IAB :)).

Regards,
-drc

---

From: Warren Kumari <[email-masked]>
Date: Wed, 4 Dec 2013 16:53:07 -0500

> I think it's pertinent to characterise what you mean by .alt (or .whatever). Do you mean adding .alt to the reserved list so that it is not used? Or do you mean it should be delegated somewhere? If…

Hmm...  Good question…. <runs away>

Actually I think that "both" is the right answer here, although I understand that that is not really possible. Ideally it should be marked as "Reserved, see RFC xxx" and *also* delegated to AS112. Simply reserving it so that it is not used on the big-I internet won't actually stop queries from leaking out and hitting the root. 

I am aware of the can of worms^W snakes, and understand that opening that can / box is not to be undertaken lightly.
So, I'd be OK with .alt being "Reserved" in some RFC, and that RFC also suggesting that this be delegated to AS112. The actual action could be taken later.

Yes, I fully get the irony of me saying "Don't poke the bear without reason" and then doing so. Oh well.

>> Whatever the case, .<new label> could be delegated to AS112 -- if you don't have the special source that uses the alternate namespace this will at least
>> cut down on the excess "junk" queries hitting the root.
> 

Yup. See the "Reserve in an RFC. Delegate to AS112 later, in another draft, written by someone else" cowardly proposal above :-)

> There are also many non-technical communities that have demonstrated the effectiveness of their brakes when it comes to making changes to root zone provisioning, no matter how benign the change mig…

You reckon?

> Note that I'm not commenting on any general or specific idea, just pointing out that there are dragons every which way you look if your proposal involves the root zone.

Yup. Dragons and monsters and big hairy things with sharp, pointy teeth…

W

-- 
Militant Agnostic -- I don't know and you don't either...

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 5 Dec 2013 09:36:09 +0100

On Wed, Dec 04, 2013 at 02:40:36PM -0500,
 Warren Kumari <[email-masked]> wrote 
 a message of 54 lines which said:

> I really like .alt -- it makes it clear that this is an alternate
> namespace type thing, mirrors the usenet alt convention, etc.  .p2p
> seems less descriptive, and not all alternate things are peer to
> peer.

I agree that .p2p is a bad idea. .not-dns is worse (because it is a
negative definition). For .alt, it is cute but I suspect that
convincing the Tor people to switch to onion.alt, or to convince Apple
to switch Bonjour to local.alt, will be some work...

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 5 Dec 2013 09:40:44 +0100

On Wed, Dec 04, 2013 at 08:37:28AM -0800,
 David Conrad <[email-masked]> wrote 
 a message of 93 lines which said:

> If I send my Pointed Haired Boss a note referencing pictures of him
> with farm animals on photos.onion, he may try to click/cut-paste
> that "domain name" in a browser. If he doesn't have the .onion
> overlay software installed and configured, he's likely to be
> disappointed/confused/angry 

But it is the same problem with <http://lolcats.local/>. Or, for the
matter, for <http://192.168.1.1/>. It seems you're restarting old
wars.

---

From: Chris Thompson <[email-masked]>
Date: 05 Dec 2013 12:15:46 +0000

On Dec 4 2013, Joe Abley wrote:

[...snip...]
>There was at least one study commissioned by ICANN on the prudence of
>provisioning DNAME RRs in the root zone that concluded that there was
>no obvious danger, but remember that any novel RRTypes in the root zone
>are going to need implementation time in the systems and processes
>involved in root zone management, and such changes have proven in the
>past to be neither quick nor easy.

How would such DNAMEs interact with use of BIND's "root-delegation-only"
(or equivalents, if any, in other software)? Do we have any idea how
widespread use of that option is?

When "ipv4only.arpa" appeared as a delegation in October, I did wonder
why it wasn't just an A rrset in the "arpa" zone, until I thought of
that issue. Although maybe the reasoning was actually different.

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    Roger Needham Building, 7 JJ Thomson Avenue,
Phone: +44 1223 334715       Cambridge CB3 0RB, United Kingdom.

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 5 Dec 2013 07:37:28 -0500

> to switch Bonjour to local.alt, will be some work...

I agree that while I think .alt makes sense to me, what makes sense to 
me is not what I expect upon others.
At that point .pony or stephane's .lolcats would make as much sense to a 
similar percentage of people.

I'd almost say we should name it .rfc#### which would not only be 
obvious to people who speak RFC, but would allow people to use their 
google machine to look up the RFC and learn something.

tim

---

From: Warren Kumari <[email-masked]>
Date: Thu, 5 Dec 2013 10:02:18 -0500

On Dec 5, 2013, at 7:37 AM, Tim Wicinski <[email-masked]> wrote:

> I agree that while I think .alt makes sense to me, what makes sense to me is not what I expect upon others.
> At that point .pony or stephane's .lolcats would make as much sense to a similar percentage of people.

Sure -- I don't think that the string itself is important, but rather, in the words of Connor MacLeod: There can be only one!

This is not strictly true, but I think that it seems like a good general principle. If you are going to design something that looks like the DNS, but isn't (something that looks like an overlay / uses dot separated labels / "can be entered where you normally would enter an DNS name"), don't simply pick something for your right most label, instead pick something under .alt (or whatever we decide[0]).

Convincing all existing users (e.g .local) to move under the new labor (e.g local.alt) is probably a non-starter, but perhaps things like .bit, and new things may do so…
One of the things that we repeatedly heard during the "namespace collisions" debacle was that folk would like a "safe" place where they could put non-Interent DNS things. This seems related…

Things under .alt are not real delegations and are not guaranteed to be unique. There is no registry here (in the same way that .onion was not guaranteed to be unique

W

[0]: Luckily "naming things" discussions are never political or controversial, and so this should be an easy one :-P

> 
> I'd almost say we should name it .rfc#### which would not only be obvious to people who speak RFC, but would allow people to use their google machine to look up the RFC and learn something.
> 
> tim
> 

--
What our ancestors would really be thinking, if they were alive today, is: "Why is it so dark in here?"

    -- (Terry Pratchett, Pyramids)

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 5 Dec 2013 16:05:02 +0100

> Things under .alt are not real delegations and are not guaranteed to be unique. There is no registry here (in the same way that .onion was not guaranteed to be unique

Agree.

I also think "machine-readable things" that can be reconfigured is easier to change than "naming conventions" that humans use. That kind of "already deployed" things are problematic.

   Patrik

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 5 Dec 2013 10:13:14 -0500

> Sure -- I don't think that the string itself is important, but rather, in the words of Connor MacLeod: There can be only one!

The difficulty is in the claim that these names are already "out
there".  If that is in fact true -- that these are names that are
being handed around and potentially will get into protocol slots --
then as a matter of prudence we should put all the strings in the
special-use registry, and treat them all as .invalid is.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: David Conrad <[email-masked]>
Date: Thu, 5 Dec 2013 10:36:53 -0800

On Dec 5, 2013, at 12:40 AM, Stephane Bortzmeyer <[email-masked]> wrote:
>> If he doesn't have the .onion
> But it is the same problem with <http://lolcats.local/>.

You carefully edited out the parenthetical immediately following "angry"

>> (at least with .local if my PHB is an English speaker, he might have a hint)

Yes, it's the same problem, but it is (currently) limited to essentially one TLD and one which has some (English-only) suggestion about its implications.

> Or, for the

In the sense that I'm resurrecting the same arguments used whenever the latest VC comes up with the brilliant idea of alternative roots, I suppose you could say I'm continuing a war.

With the proliferation of new TLDs, how is anyone supposed to know if a TLD is a real TLD and not some pseudo-domain that looks like a TLD but isn't really and they need some cool and nifty plugin or software package to actually make use of the name?

Regards,
-drc

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 6 Dec 2013 10:29:44 +0100

On Thu, Dec 05, 2013 at 10:02:18AM -0500,
 Warren Kumari <[email-masked]> wrote 
 a message of 69 lines which said:

> If you are going to design something that looks like the DNS, but
> isn't (something that looks like an overlay / uses dot separated
> labels / "can be entered where you normally would enter an DNS
> name"),

There is no such thing as DNS name. We talk about domain names here,
domain names exist outside of the DNS (LDAP, mDNS and other resolution
protocols).

> Convincing all existing users (e.g .local) to move under the new
> labor (e.g local.alt) is probably a non-starter, but perhaps things
> like .bit, and new things may do so…

OK, then someone has to write a RFC6761-style Internet-Draft
describing .alt, reserving it and doing so before too many new
proposals pop up (because, once a name is used, it is almost
impossible to change it). Any volunteer? (Not me, because I think that
registering .alt will be as much effort as registering .anything, so
it is pointless.)

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 6 Dec 2013 04:40:10 -0500

> registering .alt will be as much effort as registering .anything, so

I agree with Stephane something should be written to at least put it 
into digital print, though I also agree with him there is windmill 
tilting effect involved as well.

Any volunteers? Put your hand down Warren,  we have enough on your plate 
at this time (though I can assist if no one steps forward and/or 
everyone finds it a bad idea).

tim

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 6 Dec 2013 10:41:40 +0100

On Thu, Dec 05, 2013 at 10:36:53AM -0800,
 David Conrad <[email-masked]> wrote 
 a message of 60 lines which said:

> With the proliferation of new TLDs, how is anyone supposed to know
> if a TLD is a real TLD and not some pseudo-domain that looks like a
> TLD but isn't really 

I disagree with the use of depreciative words like "pseudo-TLD". A TLD
is a TLD in any case, specially if it is registered (in the USG root,
in the special domain registry of RFC 6761, etc). 

For .onion or its friends (.bit has been added to the new version of
the Internet-Draft), "non-DNS TLD" seems reasonable.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 6 Dec 2013 10:49:55 +0100

On Sun, Dec 01, 2013 at 05:48:41PM +0100,
 Stephane Bortzmeyer <[email-masked]> wrote 
 a message of 206 lines which said:

> I think a good idea to have dnsop read and discuss about it.

But I do not think it is a good thing that there are much more
messages about this proposal than about the DNS privacy drafts, which
are, IMHO, much more important, specially after the decisions in
Vancouver.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 6 Dec 2013 05:18:08 -0500

> domain names exist outside of the DNS (LDAP, mDNS and other resolution

MDNS names are _not_ domain names, sorry.  They look like domain
names, admittedly, but they're names in a different protocol.  The
trick of mDNS is to make a protocol that looks almost exactly like DNS
to a user but that works differently under the hood.  That's a trick,
however, and it depends on a separate name space.  The elephant in
dnssd WG's room -- and the very careful scoping of dnssd's charter --
is exactly this issue; it's why internationalization in the DNS using
IDNA and internationalization in mDNS is not interoperable.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: David Conrad <[email-masked]>
Date: Fri, 6 Dec 2013 07:33:14 -0800

Stephane,

On Dec 6, 2013, at 1:41 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> I disagree with the use of depreciative words like "pseudo-TLD".

I intentionally used the word from RFC 6761, section 4:

"  The specification MUST state how implementations determine that the
   special handling is required for any given name.  This is typically
   done by stating that any fully qualified domain name ending in a
   certain suffix (i.e., falling within a specified parent *pseudo-
   domain*) will receive the special behaviour. [...]"

(emphasis added)

I'll observe that changing what we call it does not address the concern.

Regards,
-drc

---

From: Christian Grothoff <[email-masked]>
Date: Sun, 01 Dec 2013 19:30:57 +0100

> The GNUnet top-level was named .gads at a time. I do not know the

The reason was that Jake strongly disliked ".gads" and suggested
".gnu" to Richard at IETF 87 and we all agreed that this would
make sense (shorter, easier to understand / remember, etc.).

> require special handling by software (for instance, "do not use DNS,

... and as I tried to point out, proposing ".alt" merely moves this
problem one level down.

> Precedent? And .local, what was it?

Unless of course our draft is excepted, which would show that IETF
is not entirely owned by companies and it willing to work with
free software developers, researchers and document issues for
normal users.  Call me an idealist, but that was my hope when
we wrote the draft.  Some at IETF have also asking the Tor
project to document it's protocols as RFCs, I guess trying to
demonstrate that IETF cares about security and privacy.

> has the right to create TLD at will. 

I'd say "IETF asserts the right", as I'm personally not sure which German
or EU law gives the IETF (or ICANN) any rights in this matter (and
no, not everybody lives in the US and is subject to US law), but I
do of course agree with the sentiment. Still, I see this primarily
as a technical issue (document! _informational_ RFC), and not a legal
one.

Happy hacking!

Christian

---

From: Jacob Appelbaum <[email-masked]>
Date: Tue, 03 Dec 2013 16:52:56 +0000

> http://www6.ietf.org/mail-archive/web/ietf/current/msg65346.html ).  I
> did not receive any reponse.
> 
> Please note that .local has some history.  I would look at it as "do not
> use that string as it is unlikely that uniqueness can be ensured".
> 

> The IETF should have a good explanation for doing that.  In my opinion
> the draft under discussion does not provide a good explanation.
> 

All the best,
Jacob

---

From: Eric (Maule) Brunner-Williams <[email-masked]>
Date: Wed, 04 Dec 2013 11:54:29 -0800

> ... the usenet alt convention ...

is not known to the corporation you may be trying to inform, so some
form of commuication to this effect is likely to be more useful than
its absence, if informing that corporation has some utility value.

-e

---

From: David Conrad <[email-masked]>
Date: Fri, 6 Dec 2013 13:01:25 -0800

Andrew,

> special-use registry, and treat them all as .invalid is.

What criteria do you propose the IESG should use?

Regards,
-drc

---

From: Joe Abley <[email-masked]>
Date: Sat, 7 Dec 2013 16:52:10 -0500

> widespread use of that option is?

I don't recall there ever being a time when the default behaviour of BIND9 was to insist on delegation-only behaviour from the *root* zone. As I remember those fun and exciting, lawyer-infested times the delegation-only behaviour was applied to all TLD zones, except those that were specified as needing to be otherwise. I presume this was an attempt to avoid calling out COM and NET explicitly.

Did I remember wrongly? Entirely possible ;-)

> that issue. Although maybe the reasoning was actually different.

I was involved in that conversation. I promoted the idea of a delegation simply because the machinery behind the scenes was built to facilitate delegations rather than the addition of arbitrary records to the ARPA zone, and the corresponding processes were similarly delegation-centric. Implementing an apex A in a daughter zone seemed like the pragmatic answer, and the authors of the draft that requested ipv6only.arpa were happy to agree.

Joe

---

From: Chris Thompson <[email-masked]>
Date: 09 Dec 2013 14:41:04 +0000

>On 2013-12-05, at 07:15, Chris Thompson <[email-masked]> wrote:
[...]
>I don't recall there ever being a time when the default behaviour of BIND9
>was to insist on delegation-only behaviour from the *root* zone. As I
>remember those fun and exciting, lawyer-infested times the delegation-only
>behaviour was applied to all TLD zones, except those that were specified
>as needing to be otherwise.

Well the BIND9 ARM says

| root-delegation-only
|
|  Turn on enforcement of delegation-only in TLDs (top level domains)
|  and root zones with an optional exclude list.

so I presume it *is* meant to apply to the root zone. In the absence
of an offending RR in the real root zone, I suppose I would have to
set up a configuration with a fake root to confirm that. 

root-delegation-only has never been a distribution BIND default, and
the words about it in the ARM should be enough to put anyone reading
them off the idea, Could it be in packaged configurations, though?
Or just in private configurations dating from the 10-years-ago
"*.com" wildcard era and not modified since?

---

From: Mark Andrews <[email-masked]>
Date: Tue, 10 Dec 2013 09:51:13 +1100

In message <[email-masked]>, Chris Tho
> "*.com" wildcard era and not modified since?

And if they have it and then some lookups will fail until they fix
their configuration.  You can say similar things about running old
servers which have bugs in DNAME handling.  One can play "what if"
games all day.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]