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

Keith Moore <> Mon, 24 October 2011 01:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1FC6521F86F6; Sun, 23 Oct 2011 18:17:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cFvrrG6Bz7v7; Sun, 23 Oct 2011 18:17:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4431921F86EE; Sun, 23 Oct 2011 18:17:45 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.mail.srv.osa []) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 86E4820D46; Sun, 23 Oct 2011 21:17:44 -0400 (EDT)
Received: from frontend2.nyi.mail.srv.osa ([]) by compute5.internal (MEProxy); Sun, 23 Oct 2011 21:17:44 -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=2ab8+ViZ27U9NFEJlh9l3c60myQ=; b=h2 tC7SBBxmGTJTc7gNDSE+ubRcWNwX4qDtaeZFmBzxwjqsBW1a4QD6eQRIGmsrdnqj MYf2w6Wv7eYdxM3UrYf3ynM0fdYLyw8HTxXAviCUGFXj2Rkc8GVH2sHF8z02Cuhj TUf4iUhtvETBLUZZZfDQfzpN1J+7ZakAFOVWhay/M=
X-Sasl-enc: y9OuLXkWY312JgkI8BhujiI98xkBJ+fvetjH0MQAZMnV 1319419063
Received: from [] ( []) by (Postfix) with ESMTPA id 6B6E7483436; Sun, 23 Oct 2011 21:17:42 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Keith Moore <>
In-Reply-To: <>
Date: Sun, 23 Oct 2011 21:17:41 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <COL118-W55403198A984BAAE44BA47B1F70@phx.gbl> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Matthew Pounsett <>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Sun, 23 Oct 2011 19:08:58 -0700
Cc: "<>" <>, "<>" <>, Doug Barton <>, "<>" <>, "<>" <>, "<>" <>, "<>" <>
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 01:17:46 -0000

On Oct 23, 2011, at 2:39 AM, Matthew Pounsett wrote:

> On 2011/10/22, at 15:21, Keith Moore wrote:
>> On Oct 22, 2011, at 2:42 PM, Doug Barton wrote:
>>> 1. I think we're all in agreement that dot-terminated names (e.g.,
>>> example.) should not be subject to search lists. I personally don't have
>>> any problems with any document mentioning that this is the expected
>>> behavior.
>> agree.  however there are standard protocols for which a trailing dot in a domain name is a syntax error.
> Any protocol that makes a standard FQDN a syntax error is itself in error.  Not to say that these don't exist, but if people are writing protocols that can't deal with a properly formatted FQDN they need to stop.  Now.

Per RFC 952, a standard FQDN does not contain a trailing dot.   Neither do email addresses nor domains in URLs.    Changing that set of embedded practices is much more difficult than changing the expectations of the relative few who currently expect names with dots to be subject to search lists.

>> Strongly disagree.  That would leave users without a protocol-independent way of unambiguously specifying "this is a fully-qualified domain name".
>> The practice of applying search lists to names with "."s in them needs to die.
> I can't agree with this statement.  As others have said, the practice of using a search list to allow 'ssh' to reach '' isn't going anywhere, and there are a lot of people that make extensive use of the convenience.

It needs to die because it's fundamentally broken.   Vanity TLDs will only make it worse.   I understand that there are sites that use it and people who are accustomed to it.   I don't pretend that we can stop them.   We can, however, explain the negative consequences of doing this (some of which might be specific to systems with multiple interfaces), and recommend that they transition away from that practice.   And recommendations for systems with multiple interfaces can be chosen in such a way as to allow search lists to break even more.