On Oct 24, 2011, at 6:50 PM, Jeffrey Hutzelman wrote: >>> So it seems that this question is already a matter of local policy, >>> which given the number and quality of the divergent views seems >>> eminently reasonable. Can we move on now? >> >> No, because relying on "local policy" is not sufficient for interoperability. > > For interoperability, one can use absolute names, with the trailing dot,
uh, no. Names with trailing dots aren't allowed in many contexts. And in some of the contexts in which they are allowed, they get "canonicalized" to names without trailing dots. > or specify that in the context of whatever protocol, all names are to be > taken as relative to the root, or use other than a printed > representation. ...so a DNS name means different things in one context than in another. Bad Idea. > In some cases this may require that implementations use > resolver interfaces which make it clear that a name to be resolved is > absolute, or that they append the empty label to relative names before > passing them on to the resolver. > > On the other hand, in user interface, which is primarily where relative > names are intended to be used, local policy is quite sufficient. no. Domain names are written on buses, billboards, business cards. They do get transcribed, quite often actually, and they need to have the same meanings when typed in as they do when clicked on. In a small number of cases, where a user gets immediate feedback after he types in the name and before a host attempts to contact a server, it might be sufficient to "canonicalize" a name, show the user how the name will actually be interpreted, and let him click "ok" before contacting the server. But even then, what if the "canonicalization" is wrong? How is the user supposed to know how to tell the software to treat the name as an FQDN? If he types in the '.', the dot will disappear when the name is canonicalized. That's not exactly effective reinforcement. It says to the user "you should not have typed in that final dot". And the practice of not using a trailing "." is nearly universal. Changing that practice is much harder than changing from IPv4 and IPv6. Some people are working way too hard to try to save something that was never a good idea in the first place. I'm not arguing that all software that currently applies searching to names with dots in them has to die a violent death, and immediately either be updated or deleted from all computers everywhere (as if...). I'm just saying that IETF should recommend against the practice of using search lists with multi-label names, and document the harm that it does. Sites can still do it if they want to, or they can manage their own transitions away from using search paths for such names, on their own timeframes. After all, this has been a practice for ~30 years in some places, nobody should expect it all to change overnight. > As long as I and the software on my machine agree on what a name I type > means, it's none of the IETF's business. (So what? It's also none of IETF's business if you _______________ <---- pick anything that is utterly senseless here) Of course, you can do whatever you want. But IETF should promote practices that make good sense, even though we realize that some people will decide for themselves to not follow them. > Can an enterprise change the name of every domain name? On machines > they control, yes. Of course they can. But it makes absolutely no sense for IETF to bless that practice or to ignore it when we know that it does harm. The presumption of the standards is that you want your machines to interoperate with other machines. If you don't want interoperability, have a day - screw things up however you want. (as long as you only affect your own machines, of course.). Nobody's forcing you to keep your machines conforming. > While I agree wholeheartedly with the notion of a unique domain name > space, I also believe that mapping a relative or abbreviated name onto > that namespace is _entirely_ a matter of local policy. That's a convenient philosophy if you _only_ care that local things interoperate with one another. > It is perhaps > appropriate for the IETF to provide mechanisms for distributing that > policy, for those who wish to use them, but not to dictate what the > policy must be. IETF's job is to help the Internet work, not to endorse every bit of local brain damage that people are attached to. > Do things get worse as new TLDs appear? Yes, sometimes. Be prepared for it to happen more often. Do you really want to rethink your naming scheme every time someone creates a vanity TLD that happens to collide with some subdomain of cmu.edu? Even if that's only once every year or three, how often does it need to happen before it's no longer worth the trouble? I mean, I'm sure that the relevant people at CMU are quite capable of evaluating that decision for themselves. An IETF RFC isn't going to tell them anything that they can't figure out already. But that's not true of Internet users, network administrators, software implementors in general. > Does that mean we're abandoning "options ndots:2"? Not aggressively. > It has faded over time, but more due to a failure to actively apply it > to newer systems than to any conscious decision that it's a problem. > > Further, given this position, I wonder why you think even a value of 1 > is acceptable in the face of vanity TLDs. Because (a) local names are essential, (b) the ability to distinguish local names from FQDNs is also essential, and (c) use of a single-label name as a local name (meaning, a name subject to local interpretation) is a very widespread and well-entrenched practice. Sites that associate address (or MX) records with vanity TLDs will lose, and they deserve to lose. > I know why I do, both from > the perspective of an IETF (it's a local policy matter, period) and for > myself (search for local names first, don't trust DNS results (yet) for > security, and write absolute names when you want to bypass search > lists). The way you write an absolute name is to include a '.' in it. Keith _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
