------ 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
I think we still need to answer the question about whether DNS
namespace should be polluted for non-DNS resolution.
I think draft-lewis-domain-names addresses your remark (it is the
domain name space, not the DNS name space).
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.
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
And maybe this could be the approach for a new root node name under
which special use names could live.
e.g.
.[]
.()
.$
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
