On Mon, 2011-10-24 at 16:58 -0400, Keith Moore wrote: > On Oct 24, 2011, at 4:52 PM, Doug Barton wrote: > > > On 10/24/2011 05:16, Keith Moore wrote: > >> That's the point - search lists are not appropriate most of the time, and > >> it's very hard for software to distinguish the cases where they are > >> potentially appropriate from the cases when they're not, and it's not > >> possible for software to do this in all cases. > > > > There's been something missing from this discussion, and I finally put > > my finger on it. TMK most stub resolvers have an option similar to this > > one from ISC's: > > > > ndots:n > > sets a threshold for the number of dots which > > must appear in a name given to res_query() (see > > resolver(3)) before an initial absolute query > > will be made. The default for n is “1”, mean‐ > > ing that if there are any dots in a name, the > > name will be tried first as an absolute name > > before any search list elements are appended to > > it. > > > > 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, 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. 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. 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. Can an enterprise change the name of every domain name? On machines they control, yes. 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. 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. > I think there's a need for IETF to document why any other value than 1 > is a Bad Idea, and more to the point, why it will break things. It's not a Bad Idea, and it doesn't break things, or at least not so badly that the convenience isn't worth it. In this, I speak from years of operational experience, not only of personal use of also that of the many users of systems I operate support. Do things get worse as new TLDs appear? Yes, sometimes. Have we mostly had to abandon use of relative names ending in .cs and other two-letter suffixes? Yes, but we _mostly_ didn't use them anyway, due to our deep namespace and the appearance of those domains in our search list (here, "foo.bar" usually means "foo.bar.cs.cmu.edu"). 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. 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 > problem isn't entirely specific to hosts with multiple interfaces. > But given that using multiple interfaces makes the problem worse, MIF > might want to take on some of the work of documenting why it will > break things. I can see how using an untrusted search list makes it worse. I can also see how using multiple sets of nameservers which provide different views of the namespace makes things worse, and I can see how using multiple interfaces makes this more likely. But, that has nothing to do with search lists and occurs even if every name is always treated as absolute. I can see two answers to this: 1) Use DNSSEC 2) Don't trust results from unsecured DNS for anything important. I fail to see how using multiple interfaces makes the problem worse, in itself. Can you elaborate? -- Jeff _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
