Subject: [DNSOP] Fwd: I-D Action: draft-chapin-additional-reserved-tlds-02.txt

From: Tim Wicinski <[email-masked]>
Date: Mon, 2 Mar 2015 17:16:04 -0500

All,

To those working on the alt-tld draft and other interested parties, this draft was recently revised today.  I am sure there are people on this list who have strong opinions on this matter.

tim

Subject: I-D Action: draft-chapin-additional-reserved-tlds-02.txt
From: [email-masked]
To: <[email-masked]>
Date: Mon, 02 Mar 2015 02:58:57 -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           : Additional Reserved Top Level Domains
        Authors         : Lyman Chapin
                          Mark McFadden
	Filename        : draft-chapin-additional-reserved-tlds-02.txt
	Pages           : 14
	Date            : 2015-03-02

Abstract:
   The Internet Domain Name System (DNS) defines a tree of names
   starting with root, ".", immediately below which are top level domain
   (TLD) names such as ".com" and ".us".  In June 1999 [RFC2606]
   reserved a small number of TLD names for use in documentation
   examples, private testing, experiments, and other circumstances in
   which it is desirable to avoid conflict with current or future actual
   TLD names in the DNS.

   There has been significant evolution of Internet engineering and
   operation practices since [RFC2606] was published.  In February 2013
   [RFC6761] defined criteria and procedures for reserving a domain name
   for special use, and established an IANA registry for such names.
   This document reserves three domain name labels for special use in
   accordance with the criteria and procedures of [RFC6761]: home, corp,
   and mail.

   It is important to note that TLD names may be reserved, in other
   contexts, for policy, political, or other reasons that are distinct
   from the IETF's concern with Internet engineering and operations.
   This document reserves TLD names only for operational and engineering
   reasons.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-chapin-additional-reserved-tlds/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-chapin-additional-reserved-tlds-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-chapin-additional-reserved-tlds-02

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: Paul Hoffman <[email-masked]>
Date: Mon, 2 Mar 2015 15:04:07 -0800

> To those working on the alt-tld draft and other interested parties, this draft was recently revised today.  I am sure there are people on this list who have strong opinions on this matter.

Now that they (finally) updated this to only be the three names that the ICANN board already decided to put aside, I think the document is fine.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Mon, 2 Mar 2015 21:30:12 -0500 (EST)

On Mon, 2 Mar 2015, Tim Wicinski wrote:

> Subject: [DNSOP] Fwd: I-D Action: draft-chapin-additional-reserved-tlds-02.txt

> To those working on the alt-tld draft and other interested parties, this 
> draft was recently revised today.  I am sure there are people on this list 
> who have strong opinions on this matter.

What was the motivation for removing .lan from the list?

I can see where .localdomain and .domain indeed won't cause any
problems, but I think .lan is still a pretty common one in use.

Paul

---

From: Tony Finch <[email-masked]>
Date: Tue, 3 Mar 2015 11:09:48 +0000

Paul Wouters <[email-masked]> wrote:

> > Subject: [DNSOP] Fwd: I-D Action:
> > draft-chapin-additional-reserved-tlds-02.txt
>

It is a common fake TLD used by home gateways for their internal networks.

I collected a list of distinct client host names from my mail servers (MX
and message submission servers) which did not match the DNS. A lot of
these will be internal names. I counted the most popular TLDs. .lan is the
4th most popular fake TLD, after .local (mDNS), .home (BT Home Hubs) and
.localdomain (trad.).

 135 internal
 137 cn
 143 ch
 146 lan
 155 hu
 163 pt
 164 za
 169 localdomain
 178 tw
 188 ua
 197 uy
 205 ca
 218 eu
 245 gr
 253 ar
 279 nl
 281 cl
 297 au
 300 es
 312 jp
 356 fr
 525 edu
 569 home
 768 pl
 796 local
 819 ru
 923 it
1071 de
1099 org
1408 br
1707 info
1814 biz
2823 uk
3582 net
3729 in
11019 com

If I only look at my MXs the list is quite different:

 107 internal
 107 se
 124 id
 124 th
 134 cz
 137 cn
 143 ch
 155 hu
 158 localdomain
 163 pt
 164 za
 178 tw
 188 ua
 197 uy
 205 ca
 218 eu
 245 gr
 253 ar
 278 nl
 281 cl
 297 au
 300 es
 312 jp
 351 fr
 480 local
 511 edu
 768 pl
 819 ru
 916 it
1071 de
1075 org
1408 br
1707 info
1814 biz
2080 uk
3569 net
3729 in
10982 com

(It seems spammers have learned not to use home gateway fake TLDs...)

For message submission I see the following:

   4 root
   4 sg
   6 fr
   6 site
   8 box
   8 it
   9 localdomain
  11 net
  14 edu
  14 localnet
  16 org
  27 internal
  44 com
 125 lan
 306 local
 382 uk
 495 home

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Portland, Plymouth, North Biscay: Westerly veering northwesterly 5 to 7.
Moderate or rough in Portland and northeast Plymouth, otherwise rough or very
rough. Squally showers. Good, occasionally poor.

---

From: David Conrad <[email-masked]>
Date: Tue, 10 Mar 2015 20:08:54 -0400

Hi,

> It is a common fake TLD used by home gateways for their internal networks.

Yeah, so I've read this draft and have hesitated to comment as I'm aware there are folks who believe it inappropriate for ICANN staff to comment on anything having to do with top-level domains in the IETF. However, as I continue to believe participation in the IETF is based on the individual, not for whom the individual works, I'm going to throw in my 2 cents on this topic with an explicit "NO HAT" placed firmly on my head.  My apologies if my participation in this discussion raises political hackles.

While I would like to declare the proposed strings as reserved as I think it would be crazy dangerous for them ever to be delegated, I'm concerned about the lack of objective criteria.  The draft states:

  '[SAC045] reports the results of a CAIDA
   measurement study [RSSAC_DNS] which found that "NXDOMAIN responses
   account for more than 25 percent of the total responses from root
   name servers observed in the study, and the top ten such strings
   account for 10 percent of the total query load.'

While true, these values will vary over time, location of collection, and myriad other reasons, probably including phase of moon. If we're going to reserve strings from ever being delegated, I believe we need to come up with some rationale beyond "because they showed up a lot at some root servers at this point in time."  If that is the only criteria, it would be relatively easy to game the stats by hiring a few botnet zombies to pump queries with names you'd like to reserve with spoofed source addresses.

Perhaps some criteria would be a combination of lots of queries over a long period of time at multiple measuring points along with some rationale for those queries to be generated (e.g., I'm told long ago Microsoft recommended the use of .CORP for internal Active Directory configurations, pointers to that documentation would explain why those queries were being generated)?

FWIW.

Regards,
-drc
(Speaking only for myself. Really.)

---

From: Mark Andrews <[email-masked]>
Date: Wed, 11 Mar 2015 11:36:22 +1100

I suspect as we get more validating resolvers / clients the entire
use of squatted tld zones will go away.

DNSSEC breaks the use of squatted TLDs without doing lots of extra
fragile steps to make it work again.

The standard response to bug reports about this is to say that such
usage was never guarenteed to work.  That if you want a private
domain do it in a namespace you control.

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

---

From: Jim Reid <[email-masked]>
Date: Wed, 11 Mar 2015 01:33:10 +0000

On 11 Mar 2015, at 00:08, David Conrad <[email-masked]> wrote:

> While true, these values will vary over time, location of collection, and myriad other reasons, probably including phase of moon. If we're going to reserve strings from ever being delegated, I believe we need to come up with some rationale beyond "because they showed up a lot at some root servers at this point in time."

In the absence of other objective, measurable data (sigh), going with what's seen at the root for some arbitrary shapshot(s) on arbitrary date(s) seems to be the least-worst option. It might even be the only option.

> If that is the only criteria, it would be relatively easy to game the stats by hiring a few botnet zombies to pump queries with names you'd like to reserve with spoofed source addresses.

The same would no doubt hold for whatever other criteria were chosen.

IMO the draft is a reasonable attempt at harm reduction. For some definition of harm. It seems ICANN's policy-making fora want the IETF to produce a list of "dangerous" TLD strings (on technical grounds) so that they can point at some RFC and say everything else can be classed as "safe to delegate". Which is at best a very misguided approach IMO.

That ship has already sailed so the WG just has to make the best job it can of the cards it has been dealt. If anyone here has better ideas on how to do that, please speak up.

I think it would be prudent to assume any new TLD strings (if there ever are any after the current round has been processed) are harmful unless the applicant can prove otherwise to a reasonable standard. But nobody's ever going to accept that.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Mar 2015 20:06:44 -0700

> In the absence of other objective, measurable data (sigh), going with what's seen at the root for some arbitrary shapshot(s) on arbitrary date(s) seems to be the least-worst option. It might even b…

"We have known-bad data; let's go with that." (louder sigh)

> The same would no doubt hold for whatever other criteria were chosen.

We don't need to be so fatalist. In fact, given that we are talking about a resource where some of the values are worth more than others, we should be much more diligent. There is no reason for us to allow "we starting finding requests for these unassigned TLDs" as a reason to allocate TLDs.

For the name ".lan", we can see that it has been used for quite over a decade to have a specific network purpose. We don't have to measure this at the roots: we can see it in examples of documentation for how to (mis-) configure your corporate LAN. That is a good enough reason to reserve it. The three that are in draft-chapin-additional-reserved-tlds-02 (.home, .corp, .mail) have the same property. Adding in ".lan" might help some small part of the (non-)Internet not have problems in the future; allowing Lantam Airlines or the Lansing Airport to have it will possibly cause some damage when it is allocated.

> IMO the draft is a reasonable attempt at harm reduction. For some definition of harm. It seems ICANN's policy-making fora want the IETF to produce a list of "dangerous" TLD strings (on technical gr…

And, fortunately, that's not what this draft says. Why impute that?

> That ship has already sailed so the WG just has to make the best job it can of the cards it has been dealt. If anyone here has better ideas on how to do that, please speak up.

Done so. Let's not be careless.

> I think it would be prudent to assume any new TLD strings (if there ever are any after the current round has been processed) are harmful unless the applicant can prove otherwise to a reasonable sta…

A rule that cannot be tested is not "prudent". Common, yes, but not prudent.

--Paul Hoffman

---

From: "John Levine" <[email-masked]>
Date: 11 Mar 2015 20:30:10 -0000

>"We have known-bad data; let's go with that." (louder sigh)

Yeah.

>For the name ".lan", we can see that it has been used for quite over a
>decade to have a specific network purpose. ... 
> That is a good enough reason to reserve it.

I agree, there's ample evidence of it being (mis)used in the wild, e.g.,
check the headers on this message.

Also, there is a large South American airline group called LAN, which
is a Spanish acronym for "national airline".  Assuming that vanity
TLDs don't totally crater, they'll be along soon enough, and they'd be
unlikely to ask for or be satisfied by anything else since LAN is
their real name, and the name everyone knows them by.

>> IMO the draft is a reasonable attempt at harm reduction. For some
>definition of harm. It seems ICANN's policy-making fora want the IETF to
>produce a list of "dangerous" TLD strings (on technical grounds) so that
>they can point at some RFC and say everything else can be classed as "safe
>to delegate". Which is at best a very misguided approach IMO.
>

Anyone who's been to a few ICANN meetings will confirm that's exactly
what the domain speculators who dominate ICANN will say.  These are,
after all, the same people who said in Singapore that all of the
technical issues with software handling new TLDs, including IDN issues
in e-mail, could be resolved in a few months.

I would be happier with a new section between sections 2 and 3 called
something like Limitations of this Document that explicitly says that
this document is only about the three or four name strings it
discusses, the authors and the IETF are making no statement about
which if any other strings might or might not merit similar treatment.

R's,
John