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

From: Suzanne Woolf <[email-masked]>
Date: Wed, 8 Jan 2014 13:18:09 -0500

Colleagues,

This new internet-draft is another request for additions to the RFC 6761 special names registry, this time motivated by an interest in reserving the names most commonly found in recent analysis of TLDs in private name spaces. The special names registration would serve to minimize the chances of collision between private and public DNS namespaces by keeping these names unassigned in the public namespace.

In addition to discussion on the merits of this specific request, I would expect the IESG to be interested in any new aspects this request brings up to the discussion we were already having on the p2p special names draft, and the usability and scalability of the process in RFC 6761.

thanks,
Suzanne

Begin forwarded message:

> From: [email-masked]
> Subject: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
> Date: January 8, 2014 10:11:28 AM EST
> To: [email-masked]
> Reply-To: [email-masked]
> 
> 
> 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-00.txt
> 	Pages           : 26
> 	Date            : 2014-01-08
> 
> 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 eight domain name labels for special use in
>   accordance with the criteria and procedures of RFC6761: localdomain,
>   domain, lan, home, host, corp, mail, and exchange.
> 
>   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-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: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 23 Jan 2014 09:47:06 +0100

On Wed, Jan 08, 2014 at 01:18:09PM -0500,
 Suzanne Woolf <[email-masked]> wrote 
 a message of 215 lines which said:

> This new internet-draft is another request for additions to the RFC
> 6761 special names registry, this time motivated by an interest in
> reserving the names most commonly found in recent analysis of TLDs
> in private name spaces. The special names registration would serve
> to minimize the chances of collision between private and public DNS
> namespaces by keeping these names unassigned in the public
> namespace.

I have two technical remarks about this draft (at the end of this
message) and important policy remarks.

1) During the discussion about .onion, .bit and so on, many people on
dnsop were apparently opposed to RFC 6761 (unless the requester was
Apple) and suggested we (the IETF) should not step on ICANN shoes and
do not make an actual use of RFC 6761. What do they think about this
draft?

2) I find no mention of the risk of "reservation through abuse". I
send many requests to many resolvers for "$random.example", then the
root sees a lot of traffic for this TLD, then Interisle flags it as
"hish risk of collisions" then the TLD is added in the special
registry and no longer available. There is nothing about this risk of
"denial of service" in the draft (no Security Considerations) and
nothing about how to prevent it.

3) The suggested behaviour is very demanding: for all the TLD
mentioned, the draft requests that libraries and resolvers treat them
as special. It will mean the modification of a lot of software. If the
goal is only to prevent name collision, delegating these TLD at the
root to AS112 could be sufficient. There is no discussion in the draft
about alternative approaches.

Now the technical remarks:

4) The draft says that libraries and resolvers SHOULD "restrict these
names to local resolution". "Local resolution" is not defined
anywhere. What does it mean? If it means the resolver SHOULD be inside
the organization, how could a library know that 192.0.2.3 is local or
not? Same thing for forwarders of resolvers.

5) The draft says "authoritative domain name server software SHOULD restrict
these names to local resolution and SHOULD NOT allow queries for
strings that use these Special-Use Domain Names to be forwarded to
the public DNS for resolution" I do not understand it at
all. Authoritative name servers are... authoritative, they do not
forward to other servers.

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 27 Jan 2014 20:40:12 -0800

> In addition to discussion on the merits of this specific request, I would expect the IESG to be interested in any new aspects this request brings up to the discussion we were already having on the…

I think the goal of the draft is worthy, but there are some details to work out:

1. The draft states that eight TLDs are to be designated “Special Use”, but doesn’t actually say for any of them *what* the special use is. For example, I know what “localhost” means; I know what it does and how to use it (it’s a synonym for 127.0.0.1 and ::1). What is “localdomain” and for what would I use it? The intent of RFC 6761 is that the seven Domain Name Reservation Considerations are a required *part* of any specification that is documenting something that requires some special name use, analogous to how all RFC’s have a “Security Considerations” section. But you wouldn’t write an RFC that was only a “Security Considerations” section, and a specification that is *only* a “Domain Name Reservation Considerations” section is equally lacking. The “Domain Name Reservation Considerations” section is a *supplement* to the actual descriptive content of the specification, not a *substitute* for it. I apologise that RFC 6761 did not set a good precedent in this regard. The examples in RFC 6761, like “test” , “invalid” and “example”, were all fairly self-evident and previously documented elsewhere. In retrospect, RFC 6761 should have spelled out more clearly what they are all used for, to set a better example to future documents.

2. The actual rules specified in the draft are incorrect. For example, for “.home”:

   Authors of name resolution APIs and libraries SHOULD restrict these
   names to local resolution and SHOULD NOT allow queries for strings
   that use these Special-Use Domain Names to be forwarded to the
   public DNS for resolution.

Names like “voyager.home” have been used to refer to a user’s home NAT gateway. The user can type “voyager.home” into their web browser and connect to their home NAT gateway’s administration page. If (as the draft advocates) the client machine’s name resolution library failed to send the “voyager.home” query to its configured DNS server, then this usage would fail.

If we want to formalise the current usage of “.home” rather than break it, then I suggest that something more similar to the rules for test names would be more appropriate:

6.2.  Domain Name Reservation Considerations for "test."

   The domain "test.", and any names falling within ".test.", are
   special in the following ways:

   1.  Users are free to use these test names as they would any other
       domain names.  However, since there is no central authority
       responsible for use of test names, users SHOULD be aware that
       these names are likely to yield different results on different
       networks.

   2.  Application software SHOULD NOT recognize test names as special,
       and SHOULD use test names as they would other domain names.

   3.  Name resolution APIs and libraries SHOULD NOT recognize test
       names as special and SHOULD NOT treat them differently.  Name
       resolution APIs SHOULD send queries for test names to their
       configured caching DNS server(s).

   4.  Caching DNS servers SHOULD recognize test names as special and
       SHOULD NOT, by default, attempt to look up NS records for them,
       or otherwise query authoritative DNS servers in an attempt to
       resolve test names.  Instead, caching DNS servers SHOULD, by
       default, generate immediate negative responses for all such
       queries.  This is to avoid unnecessary load on the root name
       servers and other name servers.  Caching DNS servers SHOULD offer
       a configuration option (disabled by default) to enable upstream
       resolving of test names, for use in networks where test names are
       known to be handled by an authoritative DNS server in said
       private network.

   5.  Authoritative DNS servers SHOULD recognize test names as special
       and SHOULD, by default, generate immediate negative responses for
       all such queries, unless explicitly configured by the
       administrator to give positive answers for test names.

   6.  DNS server operators SHOULD, if they are using test names,
       configure their authoritative DNS servers to act as authoritative
       for test names.

   7.  DNS Registries/Registrars MUST NOT grant requests to register
       test names in the normal way to any person or entity.  Test names
       are reserved for use in private networks and fall outside the set
       of names available for allocation by registries/registrars.
       Attempting to allocate a test name as if it were a normal DNS
       domain name will probably not work as desired, for reasons 4, 5,
       and 6 above.

Stuart Cheshire

---

From: George Michaelson <[email-masked]>
Date: Tue, 28 Jan 2014 15:15:03 +1000

I used to get very unhappy when big name IETF attendees would wander into a
room and say "this makes me very uncomfortable" at the mike.

So having said that, and noting I'm nobody special, and certainly not a big
name in IETF, or DNS...

"something about this makes me very uncomfortable"

we are a long way down a path of governance issues in names which makes
reserving a namespace highly politically charged. Look at what .XXX
underwent. Look at the issues around name collisions and potential
interests in names.

I like the aspect that this draft has drawn on observations of what leaks
into the global space, to suggest what might be wise to withhold. thats at
least testable, repeatable.

As to the decisive qualities? I think the IETF could step over a line very
quickly into a place it really doesn't want to be. Inform ICANN? sure. but
decide to formally try and exclude a namespace on technical grounds? Thats
big. That has implications. You'd want to be on remarkably solid ground.

And then theres the future. These are anglo-centric measurements from the
current state. At some future point, one can imagine a language group
embeds a token in name-lookup logic in some domain of activity, and it
winds up hitting the DNS and they come asking for a holdback. Are we tooled
up for that? the I8n side of things.

The jurisdictional qualities around what should or shouldnt be in the DNS
just makes me quake in my boots.

I guess I am going to have to wear come-backs around the "don't over
politicize technology discussions" and "stop trying to have a chilling
effect on a technology discussion" but I have this memory of some very very
cross words being said about .LOCAL a long time ago. and the potential for
value in the real world, and the potential for pain, attempting to reserve
or conserve a label for undoubtedly good technical reasons, in that
context.

BTW, India, Pakistan, South Africa, the Carribean, New Zealand, Australia,
Sri Lanka all understand the word "test" to have a meaning in sports, which
has very high financial value. The assumption the label .TEST has no
financial value in rugby or cricket, when worldwide TV rights negotiate for
billions of dollars seems to me to be .. well.. fraught.

and I can imagine several voices who could capitalize on .LOCAL, your local
supermarket chain amongst them.

---

From: "John Levine" <[email-masked]>
Date: 28 Jan 2014 05:26:45 -0000

>This new internet-draft is another request for additions to the RFC 6761 special names registry, this time motivated by an
>interest in reserving the names most commonly found in recent analysis of TLDs in private name spaces.

Several of these names including MAIL, HOME, CORP, and EXCHANGE have
active applications in the ICANN new gTLD round.  Some have such
egregious collisions with existing practice that the applications seem
to be dead, but others such as EXCHANGE aren't.

What, if anything, is the plan for dealing the predictable complaints
from applicants who (not totally unreasonably) would feel that the
rug's been yanked out from under them?

R's,
John

PS: I have some minor technical comments, similar to other people's,
but nothing that's hard to fix if we want to move this ahead.

---

From: Jim Reid <[email-masked]>
Date: Tue, 28 Jan 2014 10:05:48 +0000

> rug's been yanked out from under them?

Why would they complain or "have the rug yanked from under them"? [Note too that the draft uses SHOULD and not MUST.] Whatever happens with this draft is unlikely to have any impact on ICANN's current list of new gTLDs. The draft might however become another input into the risk mitigation framework that ICANN is now developing. ie There might be additional measures in place before .home (say) can proceed to delegation. That should not surprise anyone here.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 28 Jan 2014 07:52:00 -0800

On Jan 27, 2014, at 8:40 PM, Stuart Cheshire <[email-masked]> wrote:

> 1. The draft states that eight TLDs are to be designated “Special Use”, but doesn’t actually say for any of them *what* the special use is.

It does, but it doesn't call it out very well. It the middle of section 3, it says that the list is "names that may not be used for top-level domains". That is a special use: a label that can be legally used everywhere other than at the top level.

> Names like “voyager.home” have been used to refer to a user’s home NAT gateway. The user can type “voyager.home” into their web browser and connect to their home NAT gateway’s administration page.…

This document should have the effect you say: allow the query to be sent from a host to its configured DNS server. The current wording is wrong.

>       domain name will probably not work as desired, for reasons 4, 5,

That seems like a better way to go for all (?) the names in this document.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 28 Jan 2014 08:03:54 -0800

On Jan 27, 2014, at 9:15 PM, George Michaelson <[email-masked]> wrote:

> I like the aspect that this draft has drawn on observations of what leaks into the global space, to suggest what might be wise to withhold. thats at least testable, repeatable.
> 
> As to the decisive qualities? I think the IETF could step over a line very quickly into a place it really doesn't want to be. Inform ICANN? sure. but decide to formally try and exclude a namespace on technical grounds? Thats big. That has implications. You'd want to be on remarkably solid ground.

Yes, and this list seems like the most solid ground possible for either the IETF or ICANN.

> And then theres the future. These are anglo-centric measurements from the current state. At some future point, one can imagine a language group embeds a token in name-lookup logic in some domain of activity, and it winds up hitting the DNS and they come asking for a holdback.

There is a huge, easily-identifiable difference between adding a token *before* the application process that started in 2012 and then later asking for a hold-back, and adding it *after*.

> The jurisdictional qualities around what should or shouldnt be in the DNS just makes me quake in my boots.

Sure. But re-read section 3 of this draft. This is not "Lyman's and Mark's list", it is a list generated by an ICANN standing committee, then validated by empirical evidence.

> BTW, India, Pakistan, South Africa, the Carribean, New Zealand, Australia, Sri Lanka all understand the word "test" to have a meaning in sports, which has very high financial value. The assumption the label .TEST has no financial value in rugby or cricket, when worldwide TV rights negotiate for billions of dollars seems to me to be .. well.. fraught.

The document did not make that assumption. It doesn't talk about finance anywhere. For example, there is even financial advantage to owning almost any common label and seeing what is returned, even if you cannot control what is returned.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 28 Jan 2014 08:04:51 -0800

> rug's been yanked out from under them?

That plan would be for ICANN to design, not us.

--Paul Hoffman

---

From: "John R Levine" <[email-masked]>
Date: 28 Jan 2014 11:49:27 -0500

> Why would they complain or "have the rug yanked from under them"? [Note 
> too that the draft uses SHOULD and not MUST.] Whatever happens with this 
> draft is unlikely to have any impact on ICANN's current list of new 
> gTLDs.

Someone paid $185,000 to apply for .EXCHANGE, which is #567 on the 
priority list.  They haven't signed any contracts yet.

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

---

From: Lyman Chapin <[email-masked]>
Date: Tue, 28 Jan 2014 16:56:45 -0500

> 1. The draft states that eight TLDs are to be designated “Special Use”, but doesn’t actually say for any of them *what* the special use is.

Hi Stuart -

The draft was intended to capture existing observed high-volume uses of non-delegated TLD names empirically, rather than trying to determine the circumstances under which local use of a particular TLD name occurs (which might be highly various, depending on the name). Essentially, all of these names are proposed for designation as "special use" because they are already in widespread "special use" - that is, they are widely used as TLDs in name spaces that do not resolve (or do not resolve as they were intended to resolve) through the global DNS. I understand that this is different from the original intention of RFC 6761, which assumes that a name should be reserved for "special use" only when the "special use" is well understood and well documented. In this case, the names have been observed (see the references in the i-d) in "special use" contexts, but the nature of the "special use" in each case is not necessarily evident from the data.

The rationale for reserving these names for "special use" is the potential for name collision if they are also delegated as resolvable entries in the global IANA root, which could disrupt the operation and/or compromise the security of networks that are part of the global Internet but maintain locally-resolved name spaces. From the IETF standpoint, this is an O&M issue. ICANN's interest in selling these names to new gTLD applicants is orthogonal to the interest of the IETF in ensuring the stability and robustness of the Internet (including the DNS) for its users -

- Lyman

> For example, I know what “localhost” means; I know what it does and how to use it (it’s a synonym for 127.0.0.1 and ::1). What is “localdomain” and for what would I use it? The intent of RFC 6761 is that the seven Domain Name Reservation Considerations are a required *part* of any specification that is documenting something that requires some special name use, analogous to how all RFC’s have a “Security Considerations” section. But you wouldn’t write an RFC that was only a “Security Considerations” section, and a specification that is *only* a “Domain Name Reservation Considerations” section is equally lacking. The “Domain Name Reservation Considerations” section is a *supplement* to the actual descriptive content of the specification, not a *substitute* for it. I apologise that RFC 6761 did not set a good precedent in this regard. The examples in RFC 6761, like “test” , “invalid” and “example”, were all fairly self-evident and previously documented elsewhere. In retrospect, RFC 6761 should have spelled out more clearly what they are all used for, to set a better example to future documents.
> 
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 28 Jan 2014 19:41:31 -0800

On 28 Jan, 2014, at 07:52, Paul Hoffman <[email-masked]> wrote:

> It does, but it doesn't call it out very well. It the middle of section 3, it says that the list is “names that may not be used for top-level domains".

That doesn’t describe what the labels are used for. It describes what they may *not* be used for. What they *are* used for remains unspecified.

If the user types “www.host” into their web browser, the name should *not* be resolved in the global DNS. I get that. But what *should* happen with that name? Should it result in NXDOMAIN, like “www.invalid”? Should it result in 127.0.0.1 like “localhost” does? Resolved via mDNS, like “www.local”? Something else? I have no idea. If it’s the same as one of the other existing special-use TLDs, then an argument needs to be made as to why we need another reserved special-use TLD that duplicates the functionality of an existing one. These names are not supposed to be vanity names. The special-use names are there to trigger special behavior by software, and as such we probably don’t need more than one way to trigger each particular special behavior.

The current use of various de facto reserved names like “.onion” results from there being no formal IETF mechanism for documenting and discussing such uses.

The goal of RFC 6761 was to remedy this omission, and give people who feel they need such names a process to apply for such names and initiate discussion about whether such use is appropriate. That way the IETF community can be involved with these decisions about how names are used, instead of it happening outside the IETF with no IETF scrutiny or input.

I think it would be fairly easy to produce a draft documenting what “.onion” is for, how it works, and why resolving those names via the conventional DNS is not appropriate. I’d love to see a draft like that from one of the people who understands the details.

For some of the other names I don’t know what those documents would say. If people in the IETF community do know what those names are used for, having those people write and submit a quick two-page draft describing the usage would be a wonderful contribution to greater IETF understanding of what’s going on. Observing that certain weird names are hitting the root name servers is a useful first step. Understanding *why* that’s happening would be even better.

Stuart Cheshire

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 28 Jan 2014 19:47:47 -0800

On 28 Jan, 2014, at 13:56, Lyman Chapin <[email-masked]> wrote:

> Hi Stuart -
> 
> The draft was intended to capture existing observed high-volume uses of non-delegated TLD names empirically, rather than trying to determine the circumstances under which local use of a particular TLD name occurs (which might be highly various, depending on the name).

That’s a laudable contribution, thank you.

I believe that with the considerable sleuthing abilities of the IETF community, we ought to be able to take this initial set of observed data and treat it as a call to action for the IETF community, for someone to step forward and tell us *why* those names are in use, are leaking out to the root name servers, and what the intended use is for these names. (I assume that “leaking out to the root name servers and getting NXDOMAIN” is *not* the intended use.)

Stuart Cheshire

---

From: "John Levine" <[email-masked]>
Date: 29 Jan 2014 05:54:38 -0000

>I believe that with the considerable sleuthing abilities of the IETF
>community, we ought to be able to take this initial set of observed data
>and treat it as a call to action for the IETF community, for someone to
>step forward and tell us *why* those names are in use, are leaking out
>to the root name servers, and what the intended use is for these names.

Um, we already know.  They're used to name things on private networks,
often behind a NAT, and they leak out for random not particularly
interesting reasons, such as people taking their laptops on trips
which then look for the printer that lives on their office LAN when
they're connected to the wifi at a coffee shop.

On my home network I have a couple of dozen hosts, what with all the
networked printers, phones, tablets, laptops, and so forth, and
because I am a lazy guy, I give them names like kindle.lan rather than
longer global names.  My local DNS cache resolves those names to
addresses in 192.168/16.  I think that's pretty typical of small
business networks.  It's useful, but I don't see anything worth
standardizing other than don't resolve .LAN on the global Internet.

R's,
John

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 29 Jan 2014 07:21:26 -0800

> they're connected to the wifi at a coffee shop.

All that, plus "on their corporate network, there are search lists that allow shortened names; when they take their laptop off that network, they try to type in the shortened name".

--Paul Hoffman

---

From: Ralf Weber <[email-masked]>
Date: Wed, 29 Jan 2014 07:47:18 -0800

Moin!

> standardizing other than don't resolve .LAN on the global Internet.
Where shall this stop? How about .LOKALESNETZWERK (german for .LAN). 
How many domains do we want to treat special? I know this draft only
asks for 8, but some of them are on ICANNs application list.

You setup clearly does something the global DNS namespace was not
intended to do and while I know that this is very common (I worked
in companies that used .companyname) it is not intended to be used
in the global DNS namespace. So the results what happens to this
queries is undefined. That is your problem. We should not make
it (although we already did in some way) make it Internet community
problem.

I also don't think there are risks in delegation these other than
the applicants will get lots of traffic. If devices get an record
back or NXDomain doesn't matter in most cases. We already have seen 
that. We have ISPs  or hotels do NXDomain redirection and some do
it not very intelligent (the redirect every query). While we have
lots of reports that this is bad the world has not fallen over. 
People moved along.

So long
-Ralf

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 29 Jan 2014 08:10:50 -0800

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

> Where shall this stop?

> There is a huge, easily-identifiable difference between adding a token *before* the application process that started in 2012 and then later asking for a hold-back, and adding it *after*.

All names in draft-chapin-additional-reserved-tlds were in widespread use before the application process. If someone wants to start using a new TLD now, they know where to go ask for it.

> the applicants will get lots of traffic.

Others disagree. ICANN has documented many scenarios where there are security problems when what was earlier expected to either get local resolution or an NXDOMAIN starts getting real answers.

--Paul Hoffman

---

From: Ralf Weber <[email-masked]>
Date: Wed, 29 Jan 2014 08:40:38 -0800

Moin!

> All names in draft-chapin-additional-reserved-tlds were in widespread use before the application process. If someone wants to start using a new TLD now, they know where to go ask for it.
That they where in use before the new GTLD process doesn't change the fact that they were not supposed to be asked on the global DNS namespace.

> Others disagree. ICANN has documented many scenarios where there are security problems when what was earlier expected to either get local resolution or an NXDOMAIN starts getting real answers.
By risks I meant risks to the Internet as a whole. There surely is a security problem when you answer with an A record where you before gave back NXDomain for the person doing that. But that hasn't stopped people deploying NXDomain redirections and again the real problem is that you are using something in the global name space that is not supposed to be there. There are other uses of DNS where giving out an record instead of NXDomain has security implications (NXR redirections, fat finger domains, searchlists) and none of them have been treated special here. Also there are IMHO currently other more pressing security issues with the Internet than people getting an A record back for router.home.

So long
-Ralf

---

From: Joe Abley <[email-masked]>
Date: Wed, 29 Jan 2014 13:07:01 -0500

On 2014-01-29, at 11:40, Ralf Weber <[email-masked]> wrote:

> By risks I meant risks to the Internet as a whole.

A risk to the Internet as a whole is that a fragmented namespace (.LAN means something different in John's office than it does at the cafe next door; .HOME meaning something different to the thirty million subscribers of ISP X than it does to others) will restrict communication by name between endpoints on the Internet, and changes the fundamental assumptions on which protocols and applications rely to an extent that is potentially unbounded.

This is the end-to-end principle wearing a DNS t-shirt (the IP t-shirt was all cut up by a hundred million NATs, and is no good when it's cold out).

The trouble here is not recognising that namespace collisions are bad; it's (a) deciding where to draw the line between "bad" and "good enough" and (b) dealing with the political headaches of "use it, measure it, reserve it at the IETF" which costs $0 and "follow the ICANN new gTLD applicant guidebook" which costs substantially more.

Joe

---

From: Ralf Weber <[email-masked]>
Date: Wed, 29 Jan 2014 10:45:40 -0800

Moin!

> A risk to the Internet as a whole is that a fragmented namespace (.LAN means something different in John's office than it does at the cafe next door; .HOME meaning something different to the thirty…
1. The fragmented name space is a reality and has been for some time (dns split horizon search on google reveals 500k pages)
2. If endpoints use proper globally registered DNS names they will be able to communicate. If they use something else the behaviour is undefined.
I think there is more value in thinking about how we can integrate local and global naming than in trying to protect people by not allowing something to not be registered in the global name space.

> This is the end-to-end principle wearing a DNS t-shirt (the IP t-shirt was all cut up by a hundred million NATs, and is no good when it's cold out).
I don't think the DNS t-shirt looks better.

> The trouble here is not recognising that namespace collisions are bad; it's (a) deciding where to draw the line between "bad" and "good enough" and (b) dealing with the political headaches of "use…
I do recognise them. The data that we have shows that they exists. I just think that it is nothing the IETF should invest time in. While the IETF cost is significant lower than the ICANN cost I doubt that RFCs will get lawyers out of ICANNs back. I think the ship has sailed and it now is a political (layer 9) problem who can register what in the global DNS name space.

So long
-Ralf

---

From: Mark Andrews <[email-masked]>
Date: Thu, 30 Jan 2014 11:45:30 +1100

In message <[email-masked]>, Ralf Weber writes:
> > A risk to the Internet as a whole is that a fragmented namespace (.LAN mean
> s something different in John's office than it does at the cafe next door; .H
> OME meaning something different to the thirty million subscribers of ISP X th
> an it does to others) will restrict communication by name between endpoints o
> n the Internet, and changes the fundamental assumptions on which protocols an
> d applications rely to an extent that is potentially unbounded.
> 1. The fragmented name space is a reality and has been for some time (dns spl
> it horizon search on google reveals 500k pages)

And there is a difference between fragmenting namespace that you
control and fragmenting namespace that others control.

I have split horizon namespace (dv.isc.org) but I control the
contents of all versions of that namespace.  Any leaks get answered
by nameservers configured for that zone.

It doesn't have to cost you anything (other than time to setup the
registration) to get a namespace that you have control over.  There
are infrastructure zones which still do free registrations on best
effort basis.

This is about fragmented namespaces where the control is not under
a single party.  This is about pollution of / squatting on the
common namespace ".".

The squatted tld's used by software .onion, .bit etc could be
migrated to a new namespaces.  Just issue new software that looks
/ recognises in the new namespace first then in the old one for X
years.  After X years stop looking in / recognising the old namespace.
Set X to about 10 years and there will be very little old code left
when you turn off support for the namespace.  Set and compile in
the drop dead date.

> 2. If endpoints use proper globally registered DNS names they will be able to
>  communicate. If they use something else the behaviour is undefined.
> I think there is more value in thinking about how we can integrate local and 
> global naming than in trying to protect people by not allowing something to n
> ot be registered in the global name space.
> 
> > This is the end-to-end principle wearing a DNS t-shirt (the IP t-shirt was 
> all cut up by a hundred million NATs, and is no good when it's cold out).
> > The trouble here is not recognising that namespace collisions are bad; it's
>  (a) deciding where to draw the line between "bad" and "good enough" and (b) 
> dealing with the political headaches of "use it, measure it, reserve it at th
> e IETF" which costs $0 and "follow the ICANN new gTLD applicant guidebook" wh
> ich costs substantially more.
> I do recognise them. The data that we have shows that they exists. I just thi
> nk that it is nothing the IETF should invest time in. While the IETF cost is 
> significant lower than the ICANN cost I doubt that RFCs will get lawyers out 
> of ICANNs back. I think the ship has sailed and it now is a political (layer 
> 9) problem who can register what in the global DNS name space.
> 
> So long
> -Ralf
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]