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

[Suzanne Woolf <[e-mail]>]

(chair bit enabled)

On Feb 26, 2014, at 9:56 PM, Mark Andrews <[e-mail]> wrote:

> In message <[e-mail]>, "John Levine" writes:
>> 
>>> 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".
>> 
>> That's a relatively high bar for all the residential broadband users
>> who buy a router at Best Buy (Future Shop to you), plug it in, and set
>> up the router via the configuration page at http://router.home.
> 
> And why wasn't that "http://router.netgear.com" or
> "http://router.linksys.com". The router could easily serve the zone
> locally and the vendor could have a insecure delegation to it so
> it works if there are validating browsers being used.
> 
> http://router.home does not work with validating browsers.
> 
> If the CPE vendors want to use .home let them pony up the 100K for
> it rather than hijack the namespace.

There are operational reasons to care whether a name is in the special names registry, the production root zone, both, or neither-- regardless of who has authority over either or on what terms. We should probably focus on those. The DNSSEC issue is one useful set to explore, and further focus on it would be helpful. Another set of suggestions for our work is beginning to appear around refinements of standards treatment for DNS search path processing, on the grounds that much of the unpredictability of mixing namespaces and DNS scopes is based on unpredictable precedence of search path processes.

We've attempted to suggest now more than once that the special names discussions will be more useful if:

*We leave speculation on the economics and other non-technical attributes of other entities' decisions about the namespace out of it. Speculation on other mechanisms besides the one we in the IETF have (roughly, RFC 6761) for getting names into the top level namespace isn't productive, as we don't control them. We don't know when or whether ICANN will ever conduct another new TLD opening, or what will be eligible to be included, or at what price. The root zone change we have to consider is only that the old assumptions about its size stopped applying, not what the new ones might be beyond the specific commitments made by ICANN in its current root zone expansion. This is not an endorsement of anyone's actions in this space, or a condemnation either; it's an attempt to describe the situation we're actually in. 

* We separate issues of "what should be done, if anything, in the future to enable/support/protect non-DNS-protocol-specific, possibly non-global uses of the DNS namespace" from "what should be done, if anything, to improve/normalize the situation we're currently in". We have several drafts for discussion in London on options for the future, and a possible course of action for them that we work on them as refinements or replacements to RFC 6761. We also have two drafts requesting more or less that we grandfather pseudo-TLDs deployed in the absence of clear guidelines and consistent system behavior, in order to mitigate current issues caused by "hijacking" names under traditional expectations about how the root zone is managed. 

Regarding the guidance Joe proposed, our question is whether it's good guidance for the future, not so much whether it would have been in the past. We may also decide there's nothing we can do in the way of such guidance, the relevant horses have left the relevant barns, and the combination of DNS on-the-wire protocol, system behavior for scoping of names, and the policy characteristics of the namespace mean ambiguity, collision, or other sub-optimal characteristics of trying to use DNS namespace for non-DNS protocols or non-global scopes are a fact of life we can't usefully act to prevent in the future. That doesn't tell the IESG what to do with the current requests for grandfathering.

Ultimately, these issues do have to be integrated. But at this point we will get nowhere in, for example, trying to decide whether to grandfather existing names into the special names registry managed under the process in RFC 6761 based on an opinion about what a vendor might or should do in the future under an ICANN process we don't control.

thanks,
Suzanne