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

<teemu.savolainen@nokia.com> Fri, 21 October 2011 18:54 UTC

Return-Path: <teemu.savolainen@nokia.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 5C80A1F0C81; Fri, 21 Oct 2011 11:54:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.583
X-Spam-Level:
X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599]
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 9+GnTtVoNXXS; Fri, 21 Oct 2011 11:54:31 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7E78B1F0C62; Fri, 21 Oct 2011 11:54:31 -0700 (PDT)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9LIsTjq028071; Fri, 21 Oct 2011 21:54:30 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 21 Oct 2011 21:54:24 +0300
Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 21 Oct 2011 20:54:23 +0200
Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([169.254.7.8]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0339.002; Fri, 21 Oct 2011 20:54:23 +0200
From: <teemu.savolainen@nokia.com>
To: <moore@network-heretics.com>
Thread-Topic: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document
Thread-Index: AQHMj3JGB7FreQH6+EqCg+ltMTYsr5WGYYlQgABUUICAAG8GUA==
Date: Fri, 21 Oct 2011 18:54:23 +0000
Message-ID: <916CE6CF87173740BC8A2CE4430969620378524D@008-AM1MPN1-037.mgdnok.nokia.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> <71BF497E-6C6F-4EAF-817F-1478FFB51FE2@network-heretics.com>
In-Reply-To: <71BF497E-6C6F-4EAF-817F-1478FFB51FE2@network-heretics.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Company Confidential; Project=None;
x-titus-version: 3.3.8.1
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IleTS5gKgr+JhCehPOzQb7X8VPIDGtFQ+zxfOgeaBUZsOG8Ek7lD2xu5WHF5/rxKyBmC4Zgoz9lY65iVD+EwKfx/HOyCbcbCouTzciSIqgIMf/5bLh0Sai/jE6sG24Xx+7Vb5YLSzlGNh/xlWFKXjhG/VugZS7r2MiqJJ+wJiYnj7oW0F1q2Pewb5bJXqVC5toWbFgVuespx3qoYFmYIO7yzifaaSr9b380ixgq8cDxL9AfCqPWq32/ZgZAi48Q3WSxOadDP3x3m22zqpSDkV30=
x-originating-ip: [10.162.69.25]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_005E_01CC903B.FD6CFBF0"
MIME-Version: 1.0
X-OriginalArrivalTime: 21 Oct 2011 18:54:24.0657 (UTC) FILETIME=[D9EFF010:01CC9022]
X-Nokia-AV: Clean
Cc: dhcwg@ietf.org, dnsop@ietf.org, mif@ietf.org, dnsext@ietf.org
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 18:54:32 -0000

Now that more people are involved in discussions, this bare name / DNS
search list area seems to look like quite a deep swamp without clear IETF
consensus.

Perhaps we should discuss first if this particular topic (=section 4.6) is
needed in this document at all, because, after all, the focus is on
selecting the DNS server based on matching domains. 

Best regards,

	Teemu

> -----Original Message-----
> From: ext Keith Moore [mailto:moore@network-heretics.com]
> Sent: 21. lokakuuta 2011 17:10
> To: Savolainen Teemu (Nokia-CTO/Tampere)
> Cc: brian.e.carpenter@gmail.com; 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
> 
> 
> 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
>