Adrien, On Thu, Apr 7, 2016 at 7:13 PM, Adrien de Croy <adr...@qbik.com> wrote: > ------ Original Message ------ > From: "Stephane Bortzmeyer" <bortzme...@nic.fr> > To: "Adrien de Croy" <adr...@qbik.com> > Cc: "Philip Homburg" <pch-dn...@u-1.phicoh.com>; "dnsop@ietf.org" > <dnsop@ietf.org>; "Ted Lemon" <ted.le...@nominum.com> > Sent: 8/04/2016 3:06:43 a.m. > Subject: Re: [DNSOP] Alternative Special-Use TLD problem statement draft > >... > > OK, I read draft-lewis-domain-names-02.txt > > I guess in so far as it deals with this subject matter that is correct. > > Even though it has a few issues (e.g. not really contemplating prohibited > characters in domain tokens) the issue here is philosphical, and given that > the stated intent in the draft is to provide a justification for allowing > alternate resolution protocols into the domain name space, it's not really > discussing that issue. > > Most of the examples given of uses of alternate interpretations of domain > names, in my experience do not do that (e.g. DHCP, FTP, X.509, SSH). As far > as I can tell only MDNS and TOR are where the real divergence lies, and it's > really only TOR that fundamentally departs from DNS design. MDNS retains > the hierarchical nature, the token limits etc. All that is changed is the > character set (I'm glad punycode was abandoned). > > The evaluation of the historical origins of domain names could be argued > another way, rather than used as an argument to diverge from the point we > converged on with 1035, we could argue that this convergence was the enabler > for the DNS to become what it is, and we should discard that (no matter its > warts) at our peril. > > Given that there are so many illegal characters in domain tokens, another > option would have been to use a final token that contains illegal > characters.
There are no illegal characters for DNS labels. DNS is a binary clean protocol. All possible 8-bit bytes are permitted in labels and there is an easy way to write even kludgy ones like the zero valued byte in Master Files. See RFC 4343 for example. > e.g. if the TOR authors wanted to ensure their names would fail in a DNS > resolver, they could have used any number of illegal characters in the final > token. E.g. .[onion] instead of .onion I would avoid square brackets. To the extent they are supposed to do anything, they are supposed to indicate that the stuff between the square brackets is an IP address, as in [8.8.8.8], although admittedly the IETF has been less than successful in getting this syntactic distinction to stick. > And maybe this could be the approach for a new root node name under which > special use names could live. > > e.g. > .[] > .() > .$ I don't see any sense in which these are new roots. They look like OK two or in the last case one byte TLDs in the DNS to me although you certainly might have to escape the characters in some interfaces. If you want to be obscure, how about .\0 or .\255 instead of .alt... Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com > Or something. I'm sure some of these would cause parsing problems in some > protocols, but I'm sure something could be found. > > Although it might look like it, I'm not against novel resolution mechanisms > per se. What I have a problem with is creating a requirement to deploy new > DNS resolvers to all the billions of existing deployments. Because that's > simply impossible. > > Backward compatibility needs its priority elevated IMO. > > Adrien > > > > > >> >> _______________________________________________ >> 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
