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

[Lyman Chapin <[e-mail]>]

On May 26, 2015, at 3:48 PM, Francisco Obispo wrote:

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

Hi Francisco -

We don't know each other, but if I may assume that you work for Uniregistry (apologies if I'm jumping to the wrong conclusion from the domain name in your email address), you have a clear conflict of interest as a gTLD applicant for "home". Your viewpoint and comments are still valuable, and I mean no disrespect when I suggest that you have a conflict; but I hope that when Tim and Suzanne refer to "consensus of the WG" they mean "except for WG participants who have a clear COI".

Your other comments have been taken up by others on the list. The one I find particularly troubling is "how do we balance risk vs. benefits?" I suspect that a lot of our disagreement about delegating these names comes from very different assessments of what the "benefits" might be. Built into the new gTLD program is the assumption that the benefits are enormous - large enough, at any rate, to convince ICANN to set the bar for name collision harm at "Is the issue causing clear and present danger to human life?" (https://forms.icann.org/en/help/name-collision/report-problems). That's in bold-face type, repeated twice on the NC report form. To be fair, ICANN is also willing to take NC seriously "[i]f your system is suffering demonstrably severe harm." But the clear message is that the benefits of a new gTLD outweigh the risk of all but the most grievous consequences to Internet users.

I have yet to hear a disinterested argument that the benefit of delegating corp, home, or mail outweighs the risk of operational instability. Maybe I'm just old school, but my instinct is to err on the side of operational stability unless the benefit of doing otherwise is clear and strong. I don't see that in this case.

Having heard no (disinterested) objection to putting corp, home, and mail in the special-use name registry defined by RFC 6761, perhaps the WG chairs would proceed with a call for adoption of draft-chapin-additional-reserved-tlds-02 -

- Lyman

> 
> 
>>> * 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]
> 
>