On Dec 3, 2013, at 9:27 AM, Ted Lemon <ted.le...@nominum.com> wrote: > On Dec 3, 2013, at 12:08 PM, Stephane Bortzmeyer <bortzme...@nic.fr> wrote: >> If we want actual testing of the ability to run non-IN classes, I >> accept donations in bitcoins to do so in my lab :-) But, anyway, you >> have very little chance of convincing any developer to spend time in >> this direction, which is clearly dead. > > Furthermore, it doesn't even address the problem, because the problem we are > talking about is a naming problem, not a problem that exists within the DNS > protocol. So by definition you can't solve it with classes, because classes > are a DNS thing.
If it isn't a DNS thing, then why is there a discussion of the allocation of top-level _domains_? If these applications aren't making use of the DNS, then why does anyone care if they use something that looks like a domain name? The issue here is that they are, in fact, using the DNS in the sense that they are using applications that expect to query a local DNS stub resolver and they are (presumably) expecting that resolver to distinguish between a query for a "regular" domain name and one of these non-DNS "domain names". The reason they can't use classes is because there isn't a convenient mechanism to specify an alternative class using the vast majority of applications, hence a fallback to distinguishing using "special" names. I have significant concerns that this is not going to scale. There needs to be a better discriminator than simply "because I wrote an RFC that describes a protocol that assumes a top-level domain". Regards, -drc
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
