Re: [DNSOP] followup and proposed actions: RFC 6761 interim and next steps

[Francisco Obispo <[e-mail]>]

> 
> On May 26, 2015, at 11:50 AM, Lyman Chapin <[e-mail]> wrote:
> 
> Hi Suzanne -
> 
>> HOME/CORP/MAIL (draft-chapin-additional-reserved-tlds-02):
>> 
>> * This is the most controversial of the RFC 6761 drafts and the one most driven by policy concerns
> 
> It is not driven by policy concerns; it is driven by operational concerns, and I have heard almost no one in the WG discussion argue that these three names should *not* be withdrawn/reserved (and I say "almost" just to be safe, as I haven't checked thoroughly enough to omit it).
> 

I’m against withdrawing/reserving these names.


>> * The draft assumes that these names are commonly being used in local DNS contexts and often “leak” into the public internet. Specific uses are not documented.
> 
> The draft does not "assume" this, it "recognizes" or "observes" it. "Assumes" suggests that the authors of the draft weren't really sure about the local-context usage of these names, and so just "assumed" that it was was a problem. Specific uses are of course documented in great detail in the name collision study report (https://www.icann.org/en/system/files/files/name-collision-02aug13-en.pdf), which is 197 pages long and presumably would not be welcome as a cut-and-paste addition to a document intended only to follow the rules established by RFC 6761 for adding names to the special-use names register.
> 

It makes a lot of assumptions. As a TLD operator, I have not seen any operational problems with the names that were under names collision. This does not mean there there aren’t any.

Taking an excerpt fromR RFC6761:

   Now, suppose a
   developer were to use this special "guaranteed nonexistent" name,
   "knowing" that it's guaranteed to return NXDOMAIN, and suppose also
   that the user's DNS server fails to return NXDOMAIN for this name.
   The developer's software then fails.  Who do the user and/or
   developer complain to?  ICANN?  The IETF?  The DNS server operator?
   If the developer can't depend on the special "guaranteed nonexistent"
   name to always return NXDOMAIN, then the special name is worthless,
   because it can't be relied on to do what it is supposed to.


How is the IETF supposed to “guarantee nonexistence” ? how is ICANN going to do it?

In my opinion, defining it in “Protocol” won’t fix it, because we’re talking about “private” networks not “intended” to be connected to the Internet leaking traffic to the outside world, this is going to happen regardless of what the IETF does or does not do.

I believe there is a bigger security risk when I can’t register the name and not have a full top-down DNSSEC validation chain for my users. What is the message that we want to send?,

“… sure use .HOME for local networks because it’s guaranteed that you’ll never receive an address there, so you can trust that the IP that you are receiving comes from your intranet.."


>> * The most commonly used justification for this reservation was the risk of name collision if ICANN delegates these names in the production root zone.
> 
> More specifically, with respect to why this matters to the IETF, the justification was the risk of operational instability when names that were chosen to anchor local domain name trees precisely because they "will never resolve in the global DNS" are actually resolved by the global DNS.

Those names were resolving (in some cases) before the new GTLD program started, NX Redirection is not new within ISPs.

How do we measure the real Risk? how do we balance risk vs. benefits? I have not seen any hard data on the risk just speculations.

I have seen people implement Intranet names under COM they don’t own, but they used them for their own local network, is there a risk here? is it the same risk?, I personally think there isn’t any, people are free to shoot themselves in the foot at any time, having them wear steel toe shoes won’t solve the problem.

> 
>> * Since ICANN has said that they’re not currently planning to delegate these names, the justification further seems to assume that ICANN’s assurance of this is not a sound basis for believing that risk is contained
> 
> ICANN's decision is in the realm of policy. It is in no way disrespectful of ICANN to say that a policy decision to withhold "for now" the delegation of specific names is not the same as an operational stability decision to permanently reserve those names for local ("special") use.

If they want to be “reserved” for local use, I’m ok with it in the sense that it can be done, lets not waste time then on the assumptions and draft a document that describes those three TLDs as reserved for local use and turn the page.


> 
>> * There were questions about how to quantify name collision risk, or otherwise set a threshold for what operational characteristics of the appearance of a given name in the public internet would justify a conclusion that it should be “protected” by the IETF from delegation in the production root zone
> 
> That's not what our draft was about. Our draft was about following the rules duly established by RFC 6761 to add 3 specific strings to the special-use names registry. Full stop.
> 

If we want to make assumptions, I’ll make one:

I believe the delegation of HOME/CORP/MAIL provides with more benefit than risks, there will be more companies/homes and mail users happy because their names resolve from everywhere, they can validate with DNSSEC, they can opt who can connect to their networks and no longer require domain hacks to get their users to go to the right places.

If the problem is really about the “intent” that those TLDs where meant to be used “locally”, reserving them “forever” seems for a really long time, I would leave enough room to revisit this in the future because the TLD will outlive the systems that were misconfigured, and also the people who are in this forum (including me).

I much rather like to see us work on a transition plan on how to delegate them and not withdraw them in stone “forever”.

Best regards,



> - Lyman
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop

Francisco Obispo
CTO - Registry Operations
____________________________

 <http://www.uniregistry.com/>
2161 San Joaquin Hills Road
Newport Beach, CA 92660

Office [phone] x4202
[e-mail]