I’ve read this draft and began to reply a few times, but keep changing my mind on how to respond.
On Jan 5, 2015, at 19:32, hellekin <helle...@gnu.org> wrote: > On the other hand, if we want to keep a sane base, we'd rather identify, > circumscribe and announce the various existing strategies, and hope that > future strategies that may or may not appear will have a solid > foundation for incorporating their innovative strategy into the global > name space. Our group chose the latter. Here’s where I think a problem lies. “the global name space.” Specifically the word “the." What I read in the draft is that there are four different name spaces which are using identifiers that resemble the printed version of a DNS identifier. (The four being GNS, Tor, and the two for the latter two applications.) By “the printed version” of a DNS identifier I am differentiating from the on-the-wire form of a domain name (which has no dots in it). “Resemble” refers to the desire for general purpose applications to be able to treat, as commonly as possible, the names regardless of the appropriate mechanism for resolution in the correct name space. This kind of parallels the situation surrounding the DBOUND (not-yet-but-maybe-soon-WG) activity. That activity involves a set of applications using identifiers that happen to be based on domain names (a little stronger than resembling them). The significant difference between this draft and DBOUND is that this draft is about “resolving” the idenfitier to a service point, DBOUND is about “knowing what administrative/security properties” to apply to an identifier. >From what I’ve read in the draft, the rules for special use, and in the >thread, is that there’s a desire that identifiers in these four other (other >than DNS) name spaces to never touch the DNS. Not simply avoid collisions but >to outright and completely avoid the DNS packet stream, so that the queries >aren’t even witnessed by those who can see DNS packet traffic. And if for >some reason the queries do leak to the DNS, the DNS should act as if the >domain name corresponding to the identifier does not exist. Which the DNS >does today, meaning, the draft wants status quo for the DNS, in the protocol >and in allocation. I.e., the identifiers are not special to the DNS, the desire is that they are never added to any root zone - the global public Internet or any other. Most of the leaked traffic would go to the global public Internet, which is largely managed via the ICANN processes (I’ll skip the extensive caveats to apply here) so one can think to focus there. Anyone can stand up a DNS server and load their own root zone into it with the strings mentioned in the draft - and since there’s always “old code” around, nothning can stop the DNS protocol from serving up colliions with these names. Sorry for this path, but, I keep coming back to - there’s no reasonable change to the DNS protocol that can prevent (and I mean prevent) any mishaps - keeping in mind that the whole DNS angle here only comes in when the applications “leak” the identifiers. What is needed is a change to all applications that handle identifiers that resemble printed domain names so that they know how to resolve the names. They need to know when an identifier is a GNS identifier or a Tor identifier. (Would leaking a GNS identifier to Tor be as bad as leaking it to DNS?) That’s a problem to be solved, even if this draft is not the place to do it. WIthout this, it’s likely that identifiers will leak all over. What I’m commenting does not directly answer whether the draft fulfills the requirements for an application to the special needs registry. At some higher level I wonder that even if these names were listed there whether the problem of managing the identifiers will be solved. The desire to have name spaces besides the DNS name space is definitely legitimate, the technical barrier is how to know what space an identifier belongs to if the same syntax is shared. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
