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

Keith Moore <> Mon, 24 October 2011 11:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1689221F8D0A; Mon, 24 Oct 2011 04:30:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.664
X-Spam-Status: No, score=-3.664 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5KjWjx7pmI0T; Mon, 24 Oct 2011 04:29:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 564B621F8D10; Mon, 24 Oct 2011 04:29:59 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.mail.srv.osa []) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id E30F22069D; Mon, 24 Oct 2011 07:29:58 -0400 (EDT)
Received: from frontend2.nyi.mail.srv.osa ([]) by compute3.internal (MEProxy); Mon, 24 Oct 2011 07:29:58 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=jAXQvOkjqKiLN+83phnbP3ADYoA=; b=sD 0now8Xf63AyRMiplS5cWsJdp2t00qNDfDtgqJqi07FujJr4QgP18OauqL6KieZ/+ kVbFZ+FOnr6J4vUzWUwmWsEcyKGCtV0IkB4to93PSQE9404QStuFG5ygSibIQYBr ZpzGpr1H7qVcqMmtR9RA71jhUr7xy0Nxqpz6OY7W4=
X-Sasl-enc: +XEezKKO7/7jLeKv5Zb3tBJvhlp1ghuET5P0asA+ObTA 1319455798
Received: from [] ( []) by (Postfix) with ESMTPA id B3B4748336D; Mon, 24 Oct 2011 07:29:56 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Keith Moore <>
In-Reply-To: <E68B291B136EE9E8CFBF68F0@Ximines.local>
Date: Mon, 24 Oct 2011 07:29:55 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <E68B291B136EE9E8CFBF68F0@Ximines.local>
To: Alex Bligh <>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Mon, 24 Oct 2011 04:49:17 -0700
Subject: Re: [mif] [DNSOP] [dnsext] 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 11:30:00 -0000

On Oct 24, 2011, at 7:19 AM, Alex Bligh wrote:

> --On 24 October 2011 06:53:05 -0400 Keith Moore <> wrote:
>> I'm just pointing out that for the vast majority of the contexts in which
>> domain names are used, the expectation is that a domain name that
>> contains a "." is fully-qualified.
> This is sampling bias.

No, I don't think so.  The vast majority of contexts where domain names are used, are contexts in which the domain is supplied by one party and (at least potentially) used by another party.  Email addresses, URLs, domain names written on advertisements and business cards, etc.  

> The question here should be "where search lists are used, are
> they frequently used in combination with domain names that
> are not fully qualified". I would suggest the answer to this
> question is "yes".

That's not a useful way to phrase the question, because there's no way for software to know whether or not the user intends that a name containing "." is fully-qualified.

> If so, then to the extent that search lists
> are supported, you need to make them interwork names with
> dots in them. Moreover, with a search list of "",
> having "mail" work, but not "" is going to be a
> pretty surprising outcome.

It will be surprising to that relatively small portion of users that relies on search lists being applied to multi-label names.   But overall, having a clear, visible distinction between names for which searching is potentially applied (i.e. bare or single-label names), and names for which searching is not applied (multi-label names) results in less surprising behavior for everyone.

> I think the two options are either deprecating search lists
> (or not supporting them), or supporting them properly, in
> which case they must be used whatever domain name is
> specified, and the way to avoid using a search list
> is the same old hack as before (i.e. putting a dot on the
> end).

Supporting search lists "properly" is NOT using them whenever a domain name is specified.  That makes all domain names context-sensitive, and breaks every application that uses domain names supplied by other parties or in other contexts.