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

Doug Barton <> Mon, 24 October 2011 20:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0694F11E80A4 for <>; Mon, 24 Oct 2011 13:52:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.067
X-Spam-Status: No, score=-3.067 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D7R2Q9RQQ8W0 for <>; Mon, 24 Oct 2011 13:52:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F37DC21F8C42 for <>; Mon, 24 Oct 2011 13:52:41 -0700 (PDT)
Received: (qmail 11010 invoked by uid 399); 24 Oct 2011 20:52:36 -0000
Received: from unknown (HELO ( by with ESMTPAM; 24 Oct 2011 20:52:36 -0000
Message-ID: <>
Date: Mon, 24 Oct 2011 13:52:34 -0700
From: Doug Barton <>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1
MIME-Version: 1.0
To: Keith Moore <>
References: <> <> <> <> <> <E68B291B136EE9E8CFBF68F0@Ximines.local> <> <AFC2B32D1BE5A9E449B8D8A1@Ximines.local> <>
In-Reply-To: <>
X-Enigmail-Version: undefined
OpenPGP: id=1A1ABC84
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Cc:,,,, Alex Bligh <>,
Subject: Re: [mif] [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: Mon, 24 Oct 2011 20:52:44 -0000

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:

        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

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?



	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)