> On Jan 7, 2015, at 8:59 AM, Tony Finch <d...@dotat.at> wrote: > > Andrew Sullivan <a...@anvilwalrusden.com> wrote: >> >> In the other case, it's an indication that the _namespace_ is >> different: that if you resolve that name on the Internet without >> special enabled software, you aren't getting the service you desired, >> regardless of the protocol you happen to be using. In theory, these >> kinds of applications actually ought to want a new DNS class; but >> since classes are broken (because of CNAMEs/DNAMEs and also because of >> the facts of deployed infrastructure), in-band signalling in the >> domain name is the preferred alternative. > > Classes are the wrong thing for this purpose, because I don't think these > are separate namespaces - they are different resolution mechanisms for > particular parts of the same hostname namespace. There already examples of > similar splits, e.g. mDNS using .local and (to some extent) /etc/hosts > (though that covers the whole namespace rather than a particular part). >
Tony I disagree, in my mind different resolution mechanism implies a different namespace. I think this mechanism of identifying the lookup mechanism by the last byte in the name is BAD. I wrote this up a long time ago, and still think we should be encouraging new namespaces to address their lookups via BETTER functions rather than patching DNS resolution libraries. > You can't use classses for this purpose because applications that resolve > hostnames do not have a way to specify a name's class. But it is perfectly > feasible to install a new system resolver module which changes the way > part of the namespace works without requiring changes to any of the apps. Strictly speaking new classes do not have a resolution mechanism defined, thus Andrew is right, when one defines the use of a new class new lookup mechanism can be part of that definition. Olafur _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
