Subject: [dns-dir] Fwd: Draft requesting reservation of special-use domain names

From: Brian Haberman <[email-masked]>
Date: Fri, 15 Nov 2013 10:07:04 -0500

Any feedback from the DNS Directorate would be appreciated.

Regards,
Brian

-------- Original Message --------
Subject: Draft requesting reservation of special-use domain names
Date: Fri, 15 Nov 2013 08:35:25 -0500
From: Brian Haberman <[email-masked]>
To: IESG <[email-masked]>, "[email-masked]" <[email-masked]>

All,
     Ted and I received a request asking for assistance with the
publication of a draft reserving several special-use domain names under
the rules defined in RFC 6761.

     draft-grothoff-iesg-special-use-p2p-names puts forth a request to
reserve 5 special-use domain names.  I have indicated to the authors
that I would take a look at the draft and help determine a path forward.
 As much as I abhor AD-sponsored documents, this one does seem like a
reasonable candidate.  I may also consider running it through the
intarea WG.  I would be most interested in any policy issues that people
may see with this request and any DNS-related concerns with such a
reservation.

     Fire away!

Regards,
Brian

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 15 Nov 2013 11:11:54 -0500

Brian, welcome to the world of alternate roots, you will never be the same. 

My first thought was "Is this a joke ? " but that is too harsh.

Reserving a TLD name for special purpose that has nothing to do with IETF protocols, with no documentation on how to implement this
stuff, and a single implementation is a stretch. 

I know this is harsh standard but TLD's live on the boundary of IETF and ICANN, by reserving a 5 TLD's we are depriving ICANN of almost 1M$ in possible revenue. 

Fundamental question that needs to be asked is: 
Can a Non-DNS namespace look like a DNS namespace and share same tools to great extent? 

Personally I think a Non-DNS namespace should start with a prefix and a separator, not end with a postfix, 
	i.e. GNU#foo.bar. instead of foo.bar.gnu 
       and when people want DNS I see no harm in having DNS#foo.bar. 
with a prefix we can teach tools once for all to detect non-DNS namespaces, and do the right thing (over time) 

As in the case of they .gnu et.al postfixes these queries will leak into the DNS system thus we need to ask:
	 Do we need AS112 servers to dampen the impact? 
         Does leaking the queries to DNS constitute a security risk for the participants? 

Strictly speaking as none of the protocols are IETF ones, granting these registrations will set a horrible precedent 
and we will have to deal with lots more of these as possible ICANN tld application end-run. 

IETF has limited experience with alternate namespaces and it is a minefield of easy mistakes
Not a review, just high level questions and issues to be aware off. 

Intarea wg IMHO is a bad home for this, as I do not think any DNS people are there.
 
Patrik and possibly others are at the ICANN meeting in Argentina next week and they can offer more input on how 
the impact of something like this there. 

	Olafur

On Nov 15, 2013, at 10:07 AM, Brian Haberman <[email-masked]> wrote:

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

---

From: Brian Haberman <[email-masked]>
Date: Fri, 15 Nov 2013 11:19:46 -0500

Hi Olafur,
     Thanks for the input.  I had mentioned intarea as one possiblity
(with the hope that I could drag a few DNS folks into the discussion :)
).  Right now, the only process we have for reviewing these requests is
RFC 6761, which does not have as high a bar as what you described below.
 My main concern is that the draft does mention a goal of allowing p2p
apps to interact with DNS-based applications but, as you point out, does
not describe any of those mechanisms.

     I will definitely keep your points in mind as this document is
reviewed.

Regards,
Brian

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 15 Nov 2013 13:34:05 -0300

Let me support Ólafur and add some spices to this:

IETF do have a few RFCs talking about reserved names. Some of the actual strings mentioned are (unfortunately) "only" in appendices and not really in normative parts of RFCs. That have created first of all a gray zone of what status certain strings have.

Secondly, I do not find it being clear what process or rather, evaluation criteria, IETF will use to accept (or not) requests like these. Can it just be ad-hoc?

I do not think that would be very smart, given the discussions about reserved names IGOs request at ICANN. IETF should be lucky they have not discovered IETF have(?) the ability to reserve names.

So, IETF must, quickly(!!!!), understand what criteria are to be used to reserve names.

See Section 2 in SAC-062 <http://www.icann.org/en/groups/ssac/documents/sac-062-en.pdf>:

> Recommendation 1: ICANN should work with the wider Internet community, including at least the IAB and the IETF, to identify (1) what strings are appropriate to reserve for private namespace use and (2) what type of private namespace use is appropriate (i.e., at the TLD level only or at any additional lower level).

That is I-D arrived now is...hmm...(un)fortunate...

   Patrik

---

From: Mark Townsley <[email-masked]>
Date: Fri, 15 Nov 2013 17:55:32 +0100

I'll add that there are some discussions occurring at the IAB and ICANN level about reserving .home as a more widely scoped .local for use in homenet. What happens there will help set precedent for what the IETF does for other use cases. 

A couple of differences with .home is that we do have an IETF effort to match it up to, and we can show that it's already being used in a similar vein as we want to use it. It's also the top most leaked tld to the DNS system, so marking it special-use actually helps as it then becomes best-practice to block it. The sticky ICANN part plays in due to 5 entities already making an application to ICANN for .home with real money. ICANNs balance sheet these days can likely afford losing a few hundred $K here and there though, and it might be wrong for them to approve this domain to anyone given how widely it has already been camped on.

I'd let .home play out a bit longer and learn from it before making any material response at all to the other.

- Mark

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 15 Nov 2013 14:23:28 -0300

More specifically, I think IETF must really fast make up their mind on what the status of Appendix G of RFC 6762 is.

   Patrik

---

From: Olaf Kolkman <[email-masked]>
Date: Sat, 16 Nov 2013 09:32:14 -0300

> So, IETF must, quickly(!!!!), understand what criteria are to be used to reserve names.

Is there any reason why these should be top level labels?  (There is not technical reason as far as I can see).

If there is no technical reason then gnu.arpa. tor.arpa. onion.arpa. or domains under pseudo.arpa could be considered.

Also, this document should have an internationalization section. The community of users is not english only is it?

We have the same issues in dns-sd.

—Olaf

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sat, 16 Nov 2013 08:01:50 -0500

> We have the same issues in dns-sd.

IFF the proponents insist on using a postfix, then the easy solution is to tell them to use a name in .arpa 
but that is quite ironic to see i2p.arpa. 

	Olafur

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 16 Nov 2013 10:09:25 -0300

> If there is no technical reason then gnu.arpa. tor.arpa. onion.arpa. or domains under pseudo.arpa could be considered.

Correct, as far as I know yes.

I can do some more digging.

   paf

---

From: Ralph Droms <[email-masked]>
Date: Sun, 17 Nov 2013 17:33:56 -0800

Brian - focusing first on the IANA registry requirements...

> RFC 6761, which does not have as high a bar as what you described below.

The IANA "Special-Use Domain Names" registry defines the registration procedures as "Standards Action and IESG Approval". So, the document must be a standards track document (rather than "IESG Approval".
 
> not describe any of those mechanisms.

Yeah ... I'm trying to understand why a p2p app would use existing resolution APIs that have been modified to accept names that adhere to the DNS syntax but are resolved outside the DNS resolution system.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Sun, 17 Nov 2013 17:46:44 -0800

> More specifically, I think IETF must really fast make up their mind on what the status of Appendix G of RFC 6762 is.

Status in what way?  I don't understand what status needs to be decided or codified.

- Ralph

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 20 Nov 2013 17:37:19 -0300

> Status in what way?  I don't understand what status needs to be decided or codified.

I want to know whether the fact a string is listed in Appendix G of RFC 6762 can be, from an IETF perspective, be delegated as TLDs in the root zone.

Note specifically that some of those strings are applied for strings in the ICANN new gTLD process.

   Patrik

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 20 Nov 2013 19:54:11 -0300

> Note specifically that some of those strings are applied for strings in the ICANN new gTLD process.

And given the political importance of this question it may be a good idea to appeal the decision ourselves and make sure we go all the way up to the appeals chain (with arguments on either side as advocati diaboli) just to make sure we did _everything_ on our side to come to the most solid decision.

Not because appeals are fun but because they serve a purpose for solidifying output and documenting that interpretation to the fullest.

Thinking out loud,

—Olaf

---

From: Ralph Droms <[email-masked]>
Date: Wed, 20 Nov 2013 19:04:00 -0500

Olaf, Patrik...

I agree with Erik's assessment of Appendix G:

> That appendix seems to have a different purpose, which is to tell those that might use ".local" for their intranet that they need to change (to avoid conflict with mDNS) and then goes on to list some names which others have been using for their intranet without conflicts.

I don't interpret Appendix G as making any formal assignment of special use to any of the listed names.

- Ralph

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 20 Nov 2013 13:20:02 -0800

> I want to know whether the fact a string is listed in Appendix G of RFC 6762 can be, from an IETF perspective, be delegated as TLDs in the root zone.

Patrick,

That appendix seems to have a different purpose, which is to tell those 
that might use ".local" for their intranet that they need to change (to 
avoid conflict with mDNS) and then goes on to list some names which 
others have been using for their intranet without conflicts.

Of course, that list was a snapshot when the RFC was written - if some 
of those get delegated as TLDs in the future the recommendation wouldn't 
be a good one any more.

Thus from my reading of appendix G its status is quite clear. It doesn't 
say anything about future use of the suggested intranet labels.

    Erik

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 27 Nov 2013 18:29:09 +0100

On 20 nov. 2013, at 22:20, Erik Nordmark <[email-masked]> wrote:

> Of course, that list was a snapshot when the RFC was written - if some of those get delegated as TLDs in the future the recommendation wouldn't be a good one any more.
> 
> Thus from my reading of appendix G its status is quite clear. It doesn't say anything about future use of the suggested intranet labels.

But people who are not IETF close readers might have interpreted this paragraph as being normative and an indication of ‘safe to use’.

In any case the question is whether we should clarify. If we do we can go two ways:
1 Using these labels: your own dumb fault, you should have know better 
2 These labels are reserved for private use, because we have been confusing, and because of wide public use suggested by various forms of documentation. The will be banned for delegation from the root: beware of collisions and undefined behavior.

I’d opt for writing such document and I’d opt for version 2.

—Olaf

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 27 Nov 2013 11:10:41 -0800

On 11/27/13 9:29 AM, Olaf Kolkman wrote:

>> Thus from my reading of appendix G its status is quite clear. It
>> doesn't say anything about future use of the suggested intranet labels.
>
>
> But people who are not IETF close readers might have interpreted this
> paragraph as being normative and an indication of ‘safe to use’.

Olaf,

I can see how a statement along the lines of
	don't use "localhost" - folks seem to be using "X" instead
can be read as an endorsement of X as opposed to X being less bad than 
localhost.

Anyhow ...

> 2 These labels are reserved for private use, because we have been
> confusing, and because of wide public use suggested by various forms of
> documentation. The will be banned for delegation from the root: beware
> of collisions and undefined behavior.
>

In light of new gTLDs it does make sense to produce a clarification, and 
#2 makes sense to me.

Question is whether that document will be strictly limited to the names 
listed in RFC 6762 or open up the door to consider other names.

    Erik

---

From: Ralph Droms <[email-masked]>
Date: Wed, 27 Nov 2013 19:57:58 -0500

> I’d opt for writing such document and I’d opt for version 2.

Is there some reason to think those names might be delegated from the root?  My understanding is that the review process for name delegation would identify such names as "not to be delegated" if there is significant use now, otherwise, they are safe to delegate. 

- Ralph

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 28 Nov 2013 10:46:59 +0100

> Is there some reason to think those names might be delegated from the root?  My understanding is that the review process for name delegation would identify such names as "not to be delegated" if th…

At this moment .corp and .home are ‘on-hold’ (indefinitely?).

There is also an SSAC recommendation to have some of these strings permanently reserved, and SSAC is looking towards the IETF (correct Patrik?)

—Olaf

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 28 Nov 2013 11:45:39 +0100

> There is also an SSAC recommendation to have some of these strings permanently reserved, and SSAC is looking towards the IETF (correct Patrik?)

A few details here:

1. SSAC do not say exactly what strings are "high risk". .HOME and .CORP can be viewed as "easy", but what about ".MAIL" etc?

2. SSAC do say that "not delegate" is not enough, we do believe some strings should explicitly be for "private use". Which matches quite well what 6762 says.

3. SSAC could have directly pointed at the Appendix G, if it was clear that that was normative, and so could ICANN. But what I heard from at least one person cc:ed is that that is _not_ normative.

Question: Can IESG/IAB make a decision on the appendix "due to widespread use, misunderstanding and unclear situations etc etc we do believe those strings should not be allocated as TLDs"?

Can IESG/IAB even say yes/no to such a question without an appeal?

Is an I-D and RFC needed that clarifies status of Appendix G?

I.e. I think some IETF action is needed. Having ICANN do "too much" instead of referring to IETF -- specifically if we go down the path of "defining some strings to be TLDs for private use" -- would be dangerous.

I think personally IETF is the body that should say not only what subset of IP address space RIRs can allocate things out of but also what subset of the available bitstring space ICANN can use. Which IETF has done with "hostname" definition (cough, cough,...) and IDN2008.

So, $10.000 question: What is the path forward for "allocation of some strings for private use"?

Do IETF need a formal question from ICANN? Would that really help?

   Patrik