Re: [mif] [dhcwg] [dnsext] [DNSOP] 2nd Last Call for MIF DNS server selection document

[Jeffrey Hutzelman <[e-mail]>]

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