Hi, I think that Andrew's effort to distinguish between a domain name and a DNS name is useful. It gives us some clear terminology to use to discuss domain names that wish to use a non-DNS name resolution method.
RFC6761 introduces a mechanism for the handling of these types of cases. In the recent cases of .onion, .gnu, .zkey etc. we have software using domain names but wishing to use a non-DNS name resolution mechanism. This is a "hand in glove" use of RFC6761. For persons wishing not to allow the use of RFC6761 for these names, it would seem that you have two options: 1. Invalidate RFC6761 indicating it was a mistake. This is not a disaster, mistakes are made and sometimes need to be rectified. 2. Form a different community for the assessment of these issues, and decide not to participate in that process. Thus, "you" are not allowing the use. Option 2 may not be such a silly idea. Some members of the community made it clear that they do not wish for DNSOP to be a clearing house for RFC6761. I assume that .gnu, .zkey, .bit communities would have the patience to wait for the formation of an alternative processing mechanism, but there is time pressure on .onion due to the upcoming work with certificates. Thus, it would seem that a decision is required from this community for the .onion case. Needless to say, I support all of these cases where software is using the domain name syntax but using a non-DNS name resolution mechanism. I provide that support because they are addressing the issue of privacy which the greater IETF community embraced with RFC7258. The DPRIVE WG are working on privacy enhancements *within* the DNS system. It is a difficult problem, though many useful contributions are emerging. The above non-DNS using softwares approach the same issue in a different manner: dont use DNS at all. The advantage of this approach is that all of the challenges that DPRIVE are wrestling with are not encountered at all. The only requirement is the registration via RFC6761. Hugo Connery -- 'If privacy is outlawed, only outlaws will have privacy.' P Zimmerman. ________________________________________ From: DNSOP [dnsop-boun...@ietf.org] on behalf of Andrew Sullivan [a...@anvilwalrusden.com] Sent: Thursday, 2 July 2015 03:42 To: dnsop@ietf.org Subject: Re: [DNSOP] More after onion? was Re: Some distinctions and a request Hi Ed, On Wed, Jul 01, 2015 at 12:26:43PM +0000, Edward Lewis wrote: > I'm sympathetic to the use the path of least resistance - e.g., use names > that syntactically are DNS names I note that the Subject: line of your note still contains a vestigial reference to the thread I started recently on this, and your message nevertheless returns to collapsing "domain names" and "DNS names". I don't know whether I've simply failed to explain the distinction I'm trying to make, or whether you reject the premise. Could you please be clear about which it is? To me, the _point_ of onion. is that it is not a DNS name. You're right that it has the same syntax -- because it is a domain name, but not (intended to be) a DNS name. The registration of the name in the special use registry would achieve that end. You might object that this distinction is extremely hard, because there's nothing about the label itself to signal this namespace shift, and unaware clients will therefore automatically just treat such names as DNS names, not special-use domain names. I happen to agree with that, but we cannot hold back this tide: it was let loose once local. became an in-band protocol switch, without any registration, in Apple's widely-deployed Bonjour service. We might wish that people hadn't abused the namespace to turn it into protocol switches as well as everything else, but the history of SRV through Bonjour shows that this technique is popular and unlikely to go away. Commanding the tide to stay back when you are neck deep in water is not likely to work. Therefore, I claim, we need to make some clear distinctions and understand what has actually happened, and then adjust to the new reality. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
