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

Jeffrey Hutzelman <> Tue, 25 October 2011 00:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F16B621F8CC4; Mon, 24 Oct 2011 17:05:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.656
X-Spam-Status: No, score=-106.656 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1dCJQgvUqE7Z; Mon, 24 Oct 2011 17:05:07 -0700 (PDT)
Received: from (SMTP01.SRV.CS.CMU.EDU []) by (Postfix) with ESMTP id EE16321F8CB8; Mon, 24 Oct 2011 17:05:06 -0700 (PDT)
Received: from [] ( [] (may be forged)) (authenticated bits=0) by (8.13.6/8.13.6) with ESMTP id p9P04sjx010043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Oct 2011 20:04:56 -0400 (EDT)
From: Jeffrey Hutzelman <>
To: Keith Moore <>
In-Reply-To: <>
References: <> <> <> <> <> <E68B291B136EE9E8CFBF68F0@Ximines.local> <> <AFC2B32D1BE5A9E449B8D8A1@Ximines.local> <> <> <> <> <>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 24 Oct 2011 20:04:52 -0400
Message-ID: <>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
Content-Transfer-Encoding: 7bit
X-Scanned-By: mimedefang-cmuscs on
X-Mailman-Approved-At: Mon, 24 Oct 2011 20:24:55 -0700
Cc:,,, Doug Barton <>,, Alex Bligh <>,,
Subject: Re: [mif] [dhcwg] [dnsext] [DNSOP] 2nd Last Call for MIF DNS server selection document
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Oct 2011 00:05:08 -0000

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