IETF Logo Mail Archive

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

Keith Moore <moore@network-heretics.com> Fri, 21 October 2011 14:10 UTC

Return-Path: <moore@network-heretics.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3295121F8AED; Fri, 21 Oct 2011 07:10:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.768
X-Spam-Level:
X-Spam-Status: No, score=-3.768 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lo6DlaJCxZ77; Fri, 21 Oct 2011 07:10:47 -0700 (PDT)
Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 6021521F8B1A; Fri, 21 Oct 2011 07:10:44 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C652921427; Fri, 21 Oct 2011 10:10:35 -0400 (EDT)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 21 Oct 2011 10:10:35 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=cRfCSQxXa5CuxeLAc8AqVR6bGf8=; b=b/ HCS9HcV76vueIB9sRyneIyxwRBxjEtzShrKef+XfVgVLINGqy2Iysea5eXR/lGSQ Q4q10dZokjR83OJExfDk/0Mece1kYdkPQE/MzgUtDBQnCc32PymS0QaUoVaNckpg HIsn4REWVKE3mnpGQCEHgZAzChtaRf/9snXOJjwqo=
X-Sasl-enc: Ha7BrwBdL6cjhz3taJOw+wulibPHp2Rydy1NpM65Lsim 1319206235
Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id F0FFF408BCC; Fri, 21 Oct 2011 10:10:33 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Keith Moore <moore@network-heretics.com>
In-Reply-To: <916CE6CF87173740BC8A2CE44309696203784B1F@008-AM1MPN1-037.mgdnok.nokia.com>
Date: Fri, 21 Oct 2011 10:10:07 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <71BF497E-6C6F-4EAF-817F-1478FFB51FE2@network-heretics.com>
References: <COL118-W55403198A984BAAE44BA47B1F70@phx.gbl> <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <121DABD1-65E8-4275-8471-9FA38D25C434@nominet.org.uk> <916CE6CF87173740BC8A2CE44309696203783EE0@008-AM1MPN1-037.mgdnok.nokia.com> <4EA09791.8010705@gmail.com> <916CE6CF87173740BC8A2CE44309696203784B1F@008-AM1MPN1-037.mgdnok.nokia.com>
To: teemu.savolainen@nokia.com
X-Mailer: Apple Mail (2.1084)
Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, john_brzozowski@cable.comcast.com, dhcwg@ietf.org, denghui02@hotmail.com
Subject: Re: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Oct 2011 14:10:48 -0000

On Oct 21, 2011, at 3:15 AM, <teemu.savolainen@nokia.com> wrote:

> Brian,
> 
> Would the following text be then ok? Please note I changed the domain addition from SHOULD to MAY, if there is going to be attempt to deprecate/redefine/update search list logics. Or do you think it should remain SHOULD?
> --
> 4.6.  Interactions with DNS search lists
> 
>   A node may be configured with DNS search list via DHCPv6
>   OPTION_DOMAIN_LIST [RFC3646] or via DHCPv4 Domain Search Option
>   [RFC3397].
> 
>   A bare name (a name without any dots) MUST be first treated as a pre-
>   DNS hostname or handled by other means that, as of this writing, are
>   under discussion in the IETF and that are out of the scope of this
>   document.  If the bare name resolution fails, the name MAY then be
>   appended with the domain information.  If the bare name is appended
>   with the domain information the described DNS server selection logic
>   SHALL be utilized for the resulting name.

Associating MUST with undefined behavior makes no sense at all.

>   Resolution for the name containing any dots SHOULD first be attempted
>   with DNS servers of all interfaces.  Only if the resolution fails the
>   node MAY append the name with search list domain(s) and then again
>   utilize improved DNS server selection algorithm to decide which DNS
>   server(s) to contact.

Names containing dots SHOULD NOT (perhaps MUST NOT) be subject to searches.  They should already be considered fully qualified.

Just because a lookup "fails" does not mean that the name is not valid.  It could fail for temporary reasons, or because the TLD server wasn't reachable.

Back before there was a .CS TLD, searching on names containing dots was common.   Lots of computer science departments had .CS subdomains (e.g. cs.utk.edu used to be my mail domain), and people were accustomed to being able to send mail to moore@cs or moore@host.cs).   Once the .CS TLD was defined it became obvious that domains containing any dots should not be subject to search.

Keith

v2.16.0 | Report a Bug | By Email