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

From: Stuart Cheshire <[email-masked]>
Date: Sun, 02 Mar 2014 07:19:40 -0800

On 26 Feb, 2014, at 06:34, Joe Abley <[email-masked]> wrote:

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

The issue is home gateway vendors who want to sell a $49 home gateway that “just works”, out of the box, without the customer having to go though some confusing registration process (that also costs them $10/year, say) to use that home gateway product in their own home. Such products ship today with “.home” hard-coded into them, and all our pontificating about registration processes is not going to change that.

Stuart Cheshire

---

From: Warren Kumari <[email-masked]>
Date: Sun, 2 Mar 2014 22:20:48 +0000

On Wed, Feb 26, 2014 at 2:34 PM, Joe Abley <[email-masked]> wrote:
>
> On 26 Feb 2014, at 5:03, Mark Andrews <[email-masked]> wrote:
>
>> In message <[email-masked]>, David Conrad
>> writes:
>>
>>> 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_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.
>
> I still don't see why we need a TLD, or a delegation/reservation under ARPA.
>

Yes, and it is -- but it means that leakages hit more folk.

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

Because for some things, people specifically do *not* want it to hit /
go through the DNS -- this is why they have done this, and *not* just
registered e.g onion.com...

For example, I'm a  *huge* Justin Beiber fan. I, and a bunch of my
fellow closet Bieberites hang out on the-bieb-is-cool.onion. (you
don't really think we want everyone to know that we obsess over every
little antic, do you?)

Last week I emailed my friend a link to
http://www.the-bieb-is-cool.onion/Justins_New_Shoes.html.
Unfortunately, he was just *so* excited to see that the Bieb has new
sneakers that he clicked on the link from his phone (which doesn't
have the ToR interceptor software installed). This, of course, means
that the "DNS like" name, which should not really be used in a DNS
context suddenly hit the DNS.  Only his recursive and the root saw
this, and that's embarrassing enough, thank you.

This is bad enough, but if people built stuff like this under
.onion.eff.org (or foo.onion.arpa), there would now be many more
people in the list who knew our shameful little secret.

Obviously this is a somewhat contrived example (after all, who
wouldn't want to make it widely known that they *love* Justin
Bieber!), but lets instead pretend I'm using an overlay network as a
political dissident, or to discuss my sexual orientation, or...

This is some of the justification behind the .ALT TLD proposal
(http://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-00) -- create
a special label to be used to denote that this is not actually a name
in the DNS context. By reserving it as a special use name:
A: It creates a "safe" namespace, secure from collision for people to
root namespaces that have no meaning in a DNS context.
B: when one of these names *does* leak (as they will), iterative
resolvers will be authoritative, with an empty zone, so
the-bieb-is-cool.onion.alt only gets seen by the iterative and goes no
further.
C: When one does go further (as they will), the root can delegate to
AS112, while can squash it.
D: 4 years from now, when someone comes along and says "I created a
shiny new directory system. I used something that looks like DNS
names, and I placed it under .pony. Please reserve that for me" the
IESG can at least say "But we told you not to do that..." They can
also a: reserve it, b: not, or c: we can have another thread about
this all again, but now at least we can nod knowingly and feel all
superior...

W
P.S: Note: I did *not* say what should happen with the current
pseudo-TLDs / colliding names. They can move under .ALT or they can
not. The IESG can reserve them, or not, or bury them in peat, or paint
them purple and dress them in wellies. I have views on what I think
makes sense, but that's a separate mail.....

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

---

From: Norbert Bollow <[email-masked]>
Date: Mon, 3 Mar 2014 10:25:35 +0100

Warren makes a strong argument in favor of .alt I think.

Another related aspect is that if something like onion.notreallydns.org
is used, with notreallydns.org registered for the specific purpose of
providing a home for one or more non-resolving dns-like names, it
is very non-trivial to guarantee that whoever has registered the
notreallydns.org name will continue paying the yearly fees forever. If
the registration lapses, an attacker could become the new holder of the
notreallydns.org domain and use it to snoop and/or serve malware...

Greetings,
Norbert

Am Sun, 2 Mar 2014 22:20:48 +0000
schrieb Warren Kumari <[email-masked]>:

> >> In message <[email-masked]>,
> >> David Conrad writes:
> >>
> > 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".
> 
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: joel jaeggli <[email-masked]>
Date: Mon, 03 Mar 2014 09:51:29 +0000

> Warren makes a strong argument in favor of .alt I think.

yeah... anything that has the potential to result in additional leakage
seems like a recipe for additional pain.

---

From: Jelte Jansen <[email-masked]>
Date: Mon, 3 Mar 2014 10:30:48 +0000

> notreallydns.org domain and use it to snoop and/or serve malware...

more generally, even if one person/institution holds that name forever,
they/it can change their mind about catching the data there (and/or
responding to it). So your protocol/security tradeoffs change when this
approach is chosen compared to reserving it for explicit non-use. While
the reservation can be pulled anyway, IMO it would be a much greater
barrier should one try to do so.

(not leaning either way myself at this point)

Jelte

---

From: Joe Abley <[email-masked]>
Date: Mon, 3 Mar 2014 13:07:09 +0000

> seems like a recipe for additional pain.

Well, except that the current proposal is to reserve (not delegate) ALT.

If we assume that leaks will happen, then they will hit the root servers and there's no opportunity to sink the queries anywhere else.

If we delegate ALT, then we have to decide where to. I can see this being contentious.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Mar 2014 13:17:56 +0000

> If we assume that leaks will happen, then they will hit the root servers and there's no opportunity to sink the queries anywhere else.

This will happen whether the special-domain is under ALT or is itself a TLD.

> If we delegate ALT, then we have to decide where to. I can see this being contentious.

It seems to me that it would be highly preferable not to delegate it.   Is there an argument for doing so?

---

From: Joe Abley <[email-masked]>
Date: Mon, 3 Mar 2014 13:22:14 +0000

> This will happen whether the special-domain is under ALT or is itself a TLD.

Ah, but in the case of a delegated ALT TLD, the referral will be cached and hence subsequent/repeated queries will be sunk elsewhere.

> It seems to me that it would be highly preferable not to delegate it.

Me too.

>   Is there an argument for doing so?

See above.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Mar 2014 13:29:03 +0000

> See above.

Right.   Ugh.   How about delegating it to 127.0.0.27?

---

From: Tony Finch <[email-masked]>
Date: Mon, 3 Mar 2014 13:32:17 +0000

> Is there an argument for doing so?

As well as Joe's AS112 argument there is also the question of DNSSEC
validation - but perhaps we don't want non-DNS names to make any kind of
sense in this respect... cf. .local

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Northwest 6 or 7, decreasing 5. Moderate or rough in far southeast,
otherwise rough or very rough, becoming high. Showers. Good.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Mar 2014 13:43:30 +0000

> sense in this respect... cf. .local

Indeed, it doesn't make much sense to me that special-use names that are not intended to be resolved using the DNS should be validateable via DNSSEC.   If they can be validated, it would have to be using whatever protocol is being used for name resolution (if any).

---

From: Jelte Jansen <[email-masked]>
Date: Mon, 3 Mar 2014 13:56:20 +0000

> Indeed, it doesn't make much sense to me that special-use names that are not intended to be resolved using the DNS should be validateable via DNSSEC.   If they can be validated, it would have to be…

+1

This is something I asked about at the app session, and have been
wondering; (why) are we worried about non-dns names at all? More
importantly, where do we draw the line? "A domain by any other name?"

Is anything sequence of characters that happens to maybe contain a dot a
domain name? Is it that it *might* end up in some code path that tries
to resolve it, even though the normal use doesn't use (the global) DNS
at all?

To make a crazy example; the left-hand side of an e-mail address also
contains dots, but we're not worried about those somehow ending up in a
resolution call. Neither were we worried about 'command.com' being
resolved (and it does).

I'd think that a domain name is only a domain name when whatever
protocol it is defined in defines it as a domain name (or whatever
undefined protocol uses it in actual dns resolution). What a non-domain
name looks like shouldn't matter.

Jelte

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 3 Mar 2014 09:03:12 -0500

> name looks like shouldn't matter.

Are NetBIOS names domain names?  How about mDNS names?  I think yes,
but neither is part of the DNS as such.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 3 Mar 2014 14:07:35 +0000

> but neither is part of the DNS as such.

NetBIOS IMHO is a different namespace but it is not treated that way by sysadmin's 
due to lack off ….. 

	Olafur

---

From: Jelte Jansen <[email-masked]>
Date: Mon, 3 Mar 2014 14:14:11 +0000

> but neither is part of the DNS as such.

I was wondering whether I should have stated that a bit more carefully,
but 'part of the DNS' might be a different thing than 'could use DNS'.

I wasn't suggesting there shouldn't be any reservations, but 'looks like
a domain name' is way, way too wide a definition. In that case we need
to reserve any possible TLD. Including all existing gTLD and ccTLD's.

As for mDNS, I do not know; you tell me :) Is there a problem in
anything that is *not* either a definite bug in a program or a user
copy-pasting the name in a browser window?

Jelte

---

From: Warren Kumari <[email-masked]>
Date: Mon, 3 Mar 2014 14:19:07 +0000

> Well, except that the current proposal is to reserve (not delegate) ALT.

Weeeeeelll....

Actually it says (Section 3):

 1.  Stub resolvers MAY elect not to send queries to any upstream
       resolver for names in the ALT TLD.

   2.  Iterative resolvers SHOULD follow the advice in [RFC6303],
       Section 3.

   3.  The root zone nameservers should either return NXDOMAIN
       responses, or the ALT TLD should be delegated to "new style"
       AS112 nameservers.  (TODO(WK): WK, JA, BD to revive AS112 /
       AS112-bis).

Item 3 is specifically about this question -- it can either be that
the root continues to not know about the ALT "TLD"[0] or it could be
delegated to a new style AS112, which will, in theory, happily sink
$whatever.

That's an open question, but (IMO) a detail.

W

[0]: Much of this draft and discussion is made complicated by
terminology problems. If someone uses www.foo.tld in their own
protocol, it the rightmost label a TLD? Probably not... But, if the
name (which is *not* a DNS name), but is "DNS like" leaks into the
DNS, then it is...

---

From: Joe Abley <[email-masked]>
Date: Tue, 4 Mar 2014 12:59:53 +0000

>       AS112 nameservers.  (TODO(WK): WK, JA, BD to revive AS112 /

New-style AS112 proposes redirection to an empty zone rather than delegation.

There's no machinery currently available to deploy a DNAME in the root zone, as far as I know. Since the IANA uses EPP to submit change requests to Verisign for implementation, and since the implementation ("RZM") has not suffered from rapid development in the past, I suspect (pragmatically speaking) this is a non-starter.

Delegation of ALT from the root zone seems likely to be interpreted as a provocative end-run around the new gTLD process and seems likely to raise eyebrows, if not hairs on the backs of necks.

I don't see an obvious path forward here. We are in a maze of twisty passages, all alike.

Joe

---

From: Warren Kumari <[email-masked]>
Date: Tue, 4 Mar 2014 14:38:14 +0000

> Delegation of ALT from the root zone seems likely to be interpreted as a provocative end-run around the new gTLD process and seems likely to raise eyebrows, if not hairs on the backs of necks.

Yes. Which is why I think that some of this involves us[0] talking to
ICANN and explaining the reason / purpose for ALT, and playing nice.
Explaining that this is not usable as a further delegation (you cannot
register a usable *DNS* name under this), and it should (hopefully)
stop people "squatting" on labels that might otherwise be available as
future TLDs should help ease over some of the uneasiness.  Basically
saying "There's an upcoming problem over here. Here's a mitigation
option, we'd like to do $foo." and not "Mine! Mine! We can do $foo and
you can't stop us, mwahaahha".

W
[0]: Read: The IETF ICANN Liaison / someone involved in both communities.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 4 Mar 2014 15:17:10 +0000

> you can't stop us, mwahaahha".

Sorry all, I'm sitting in the DNSE BoF, got over excited and clicked
send before I was really finished.

I think that the "to delegate or not delegate" bit is simply a detail
/ optimization. We also don't need to, and shouldn't go into all the
discussions about who has the right to do this, who gave them the
right, which side they crack the egg on, what size cookies they serve,
etc.
Let's figure out what the right answers are, and then figure out how
(and if) we get there from here.

W

---

From: Joe Abley <[email-masked]>
Date: Tue, 4 Mar 2014 18:48:10 +0000

> (and if) we get there from here.

I realise I have my broken record hat on, but the only problem that reserving ALT solves is avoiding collision with an ALT TLD in the DNS.

This seems good if you have the underlying assumption that all alternative namespaces necessarily need to be anchored under a TLD label.

As should be tediously and abundantly clear, I'm (a) not convinced that's a sensible assumption and (b) I think the reservation of a TLD is not sufficient anyway to deal with leaked queries.

I think we need a problem statement (and we need to test it) before we start assessing solutions. I don't agree that we can plausibly arrive at the right answers until we know the question (unless we're happy not understanding the answer, which leads us into Douglas Adams territory).

That's more than enough from me. I am throwing this hat away. :-)

Joe

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 6 Mar 2014 14:36:34 +0000

On Tue, Mar 04, 2014 at 02:38:14PM +0000,
 Warren Kumari <[email-masked]> wrote 
 a message of 39 lines which said:

> Which is why I think that some of this involves us[0] talking to

OK, so we just have to find people who accept to devote the next N
years of their life to a boring and unrewarding task, full of meetings
and thick reports, with lawyers and politicians. You've found someone?
:-)

---

From: Warren Kumari <[email-masked]>
Date: Fri, 14 Mar 2014 22:22:27 -0400

> and thick reports, with lawyers and politicians. You've found someone?

Well, I go to all the ICANN meetings already, so...

W

---

From: Tim Wicinsku <[email-masked]>
Date: Fri, 14 Mar 2014 19:33:52 -0700

Sent from my iPhone

> On Mar 14, 2014, at 7:22 PM, Warren Kumari <[email-masked]> wrote:
> 

And successfully defended a challenge from my employer's legal department to send me to ICANN. While I consider it a win though I think as WG chair I may need to go if it would help resolve this issue

---

From: Suzanne Woolf <[email-masked]>
Date: Sat, 15 Mar 2014 10:56:17 -0400

(No hat)

> And successfully defended a challenge from my employer's legal department to send me to ICANN. While I consider it a win though I think as WG chair I may need to go if it would help resolve this is…

No need for anything rash. Several DNSOP regulars are already sentenced to ICANN meetings, including myself. And given that ICANN does not currently have any mechanism for even entertaining a new TLD application of any kind, there's little point in going to an ICANN meeting to lobby for one. 

Let's do our own homework on this, first. I think TIm and I owe the group an attempt at a summary of the discussion we had in London and on the mailing list, and possible ways forward.

Suzanne