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

[Jeffrey Hutzelman <[e-mail]>]

On Mon, 2011-10-24 at 19:30 -0400, Keith Moore wrote:
> 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.

Yup; that's a problem.  And I agree that changing it may not be the most
practical solution to the problem.


> 
> > 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.

Hm?  Not at all.  Really, only unambiguous names ought to ever appear on
the wire.  One way for a protocol to do that is too use absolute names
exclusively; another is to use "relative" names which are always
relative to the root; this is the same as using absolute names without
the trailing dot.  Another is to use names relative to some unambiguous
origin, as is done in DNS master files.

The important thing is that a name always mean the same thing, not that
it be represented the same way in all protocols.


> >  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.

Yup, that's a problem, too, in many ways.  Of course, such names should
always be fully-qualified; you can't expect useful results if you use a
relative name on the side of a bus.  Or at least, you can't unless you
really meant an absolute name but left off the trailing dot, which is
what everyone will think you meant anyway.


> 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.

Right.  That's what local policy _is_.
Of course it's reasonable for the IETF to recommend default policy, and
describe some of the pitfalls associated with other possible policies.
And I certainly agree that ndots:1 is a reasonable default policy that
will work for most people while causing few problems.  Which makes it
convenient that it's what most vendors already do today.

> > 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.

I only care that abbreviated names work for local things.  For non-local
things, I find it acceptable that fully-qualified names must be used to
obtain interoperability.


> > 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.

OK; on these points we agree.

Note, however, that to me "local interpretation" means as defined by me
and whoever else is involved in setting policy for me, and _not_ as
defined by the coffee shop I happen to be sitting in.  IMHO, local names
are useless if I cannot depend on their meaning.

Ideally, it would be desirable to have an interoperable way to have
multi-label local names.  When "local" gets to be large, a flat
namespace becomes unwieldy, but abbreviation is still highly desirable.
Why should I have to type more to talk to a relatively nearby machine
that is part of my organization than to talk to a total stranger?

But, since such a thing is basically impossible, I am satisfied with the
idea that, as a matter of local policy, I can decide that some things
that would otherwise be treated as fully-qualified are instead treated
as local names.  Other people shouldn't get to decide that for me
without my permission, of course.


> >  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.

Well, yes.

-- Jeff