Re: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document
Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 21 October 2011 19:29 UTC
Return-Path: <brian.e.carpenter@gmail.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 34F5321F8B3F; Fri, 21 Oct 2011 12:29:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.089
X-Spam-Level:
X-Spam-Status: No, score=-103.089 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 yrHI8wz7X9MH; Fri, 21 Oct 2011 12:29:51 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A378421F8B3D; Fri, 21 Oct 2011 12:29:50 -0700 (PDT)
Received: by mail-bw0-f44.google.com with SMTP id s6so6056678bka.31 for <multiple recipients>; Fri, 21 Oct 2011 12:29:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JRwdP+KXzPm8ahbrR73oyzDeY8fLfo6xr/DukOIFsV8=; b=L1waKSsjziLu8EsUyV6O2WPOf5IH2Nt5MRYoWO95UfHlu7on+Jm861Ysh8UripP9M2 AWzMq3nl+5NtP20mLhRNzrx1xyvlO4nnUiwGLFp8pLvLcDPDf/99EEv3ltLsffLCl4q7 jFOsXlJ4DOHXtgEEn7wR9Jy3hr1mV5V6gJ7rs=
Received: by 10.223.76.201 with SMTP id d9mr26561529fak.12.1319225390225; Fri, 21 Oct 2011 12:29:50 -0700 (PDT)
Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id n12sm23804539fan.9.2011.10.21.12.29.44 (version=SSLv3 cipher=OTHER); Fri, 21 Oct 2011 12:29:49 -0700 (PDT)
Message-ID: <4EA1C81D.8000805@gmail.com>
Date: Sat, 22 Oct 2011 08:29:33 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: teemu.savolainen@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>
In-Reply-To: <916CE6CF87173740BC8A2CE44309696203784B1F@008-AM1MPN1-037.mgdnok.nokia.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 19:29:52 -0000
Teemu, I think that the spirit of what you propose is correct, but as Keith points out it really isn't appropriate to use RFC 2119 language about a pragmatic approach that clearly lies outside the definition of the DNS namespace. If an implementor is willing to take the risk of transforming www.example into www.example.com, because at the time of writing there is no TLD "example", that's the implementor's risk, but it shouldn't be dignified with normative keywords IMHO. Regards Brian Carpenter On 2011-10-21 20:15, 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. > > 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. > -- > > Best regards, > > Teemu > >> -----Original Message----- >> From: ext Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: 21. lokakuuta 2011 00:50 >> To: Savolainen Teemu (Nokia-CTO/Tampere) >> Cc: Ray.Bellis@nominet.org.uk; 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 >> >> Teemu, >> >> I don't believe this is a topic where consensus in MIF is very relevant. >> It needs to be decided in a much wider community rather than as a subsidiary >> question in a MIF document. I suggest leaving it FFS (for further study) in MIF. >> >> Regards >> Brian Carpenter >> >> On 2011-10-20 20:01, teemu.savolainen@nokia.com wrote: >>> Hi Ray, >>> >>>> -----Original Message----- >>>> From: ext Ray Bellis [mailto:Ray.Bellis@nominet.org.uk] >>>> Sent: 19. lokakuuta 2011 13:40 >>>> To: Savolainen Teemu (Nokia-CTO/Tampere) >>>> Cc: <denghui02@hotmail.com>; <mif@ietf.org>; <dnsext@ietf.org>; >>>> <dnsop@ietf.org>; <dhcwg@ietf.org>; <pk@isoc.de>; >>>> <john_brzozowski@cable.comcast.com> >>>> Subject: Re: [dnsext] [mif] 2nd Last Call for MIF DNS server >>>> selection document >>>> >>>> I have concerns about §4.6: >>>> >>>> "A bare name (a name without any dots) MUST be first treated as a >>>> pre- >>> DNS >>>> hostname, and only after that the name SHALL be appended with domain >>>> information and described DNS server selection logic be utilized." >>>> >>>> When new gTLDs are introduced it is likely for brand-name gTLDs that >>>> they will wish to use bare names in the DNS (i.e. a single label >>>> hostname) for >>> their >>>> primary web sites. >>>> >>>> Hence bare names may become much more frequently used as DNS >> names, >>>> and §4.6 wouldn't permit those to work unless '.' is also in the >>>> suffix >>> list. >>>> I'd like to hear the authors' thoughts on these. I'm not sure that >>>> this >>> draft >>>> necessarily needs any significant changes - it may only require >>>> changes to ensure that bare names are also considered as potential >>>> DNS names in their own right. >>> Okay, I understand there is no clear consensus yet how these single >>> label names should be handled by the resolvers at the first place? >>> Should resolver first treat them as pre-DNS hostnames, then as DNS >>> hostnames, and then try search list? The DNS server selection logic >>> would be applied already when resolving single label name, i.e. the >>> network could provide a single label domain "brand" in the domains list. >>> >>> Maybe section 4.6 could be like this, perhaps (changes in second >>> paragraph and title)? >>> -- >>> 4.6. Interactions with DNS search lists and single label hostnames >>> >>> A node may be configured with DNS search list by DHCPv6 >>> OPTION_DOMAIN_LIST [RFC3646] or DHCPv4 Domain Search Option >>> [RFC3397]. >>> >>> A bare name (a name without any dots) MUST be first treated as a pre- >>> DNS hostname, after which resolution of the name SHALL be attempted >>> with DNS, and as a last resort the name SHALL be appended with >>> domain information. DNS server selection logic SHALL be >>> utilized for both of the latter two DNS using methods. >>> >>> Resolution for the name containing any dots SHOULD first be attempted >>> with DNS servers of all interfaces. Only if the resolution fails the >>> node SHOULD 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. >>> -- >>> >>> Best regards, >>> >>> Teemu >>> >>> >>> >>> ---------------------------------------------------------------------- >>> -- >>> >>> _______________________________________________ >>> mif mailing list >>> mif@ietf.org >>> https://www.ietf.org/mailman/listinfo/mif >
- [mif] 2nd Last Call for MIF DNS server selection … Hui Deng
- Re: [mif] 2nd Last Call for MIF DNS server select… teemu.savolainen
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… Ray Bellis
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… Keith Moore
- [mif] bare names (was: [dnsext] 2nd Last Call for… Andrew Sullivan
- Re: [mif] bare names (was: [dnsext] 2nd Last Call… Keith Moore
- Re: [mif] bare names (was: [dnsext] 2nd Last Call… Andrew Sullivan
- Re: [mif] bare names (was: [dnsext] 2nd Last Call… Keith Moore
- Re: [mif] [dhcwg] 2nd Last Call for MIF DNS serve… Ted Lemon
- Re: [mif] bare names (was: [dnsext] 2nd Last Call… Margaret Wasserman
- Re: [mif] bare names (was: [dnsext] 2nd Last Call… Ted Lemon
- Re: [mif] bare names (was: [dnsext] 2nd Last Call… Keith Moore
- Re: [mif] [dhcwg] 2nd Last Call for MIF DNS serve… teemu.savolainen
- Re: [mif] [dhcwg] 2nd Last Call for MIF DNS serve… Ted Lemon
- Re: [mif] bare names Brian E Carpenter
- Re: [mif] [dnsext] [dhcwg] 2nd Last Call for MIF … Brian Dickson
- Re: [mif] [dnsext] bare names (was: 2nd Last Call… Mark Andrews
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… teemu.savolainen
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… SM
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… Brian E Carpenter
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… Keith Moore
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… Keith Moore
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… teemu.savolainen
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… teemu.savolainen
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… Ray Bellis
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… David Conrad
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… Mark Andrews
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… Brian Dickson
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… teemu.savolainen
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… Keith Moore
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … Mark Andrews
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… Keith Moore
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … Ted Lemon
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … Ted Lemon
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … Keith Moore
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … Ted Lemon
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … Keith Moore
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… teemu.savolainen
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… Brian E Carpenter
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … Keith Moore
- Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF … Keith Moore
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … Ted Lemon
- Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF … Doug Barton
- Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF … Matthew Pounsett
- Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF … Ted Lemon
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … Mark Andrews
- Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF … Keith Moore
- Re: [mif] [dhcwg] [DNSOP] [dnsext] 2nd Last Call … Donald Eastlake
- Re: [mif] [dhcwg] [DNSOP] [dnsext] 2nd Last Call … Mark Andrews
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … sthaug
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … Keith Moore
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … Alex Bligh
- Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF … Alex Bligh
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … Keith Moore
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … Alex Bligh
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … Keith Moore
- Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF … Doug Barton
- Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF … Keith Moore
- Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF … Doug Barton
- Re: [mif] [dhcwg] [dnsext] [DNSOP] 2nd Last Call … Keith Moore
- Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF … Mark Andrews
- Re: [mif] [dhcwg] [DNSOP] [dnsext] 2nd Last Call … Danny Mayer
- Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF … Lawrence Conroy
- Re: [mif] [dhcwg] [dnsext] [DNSOP] 2nd Last Call … Jeffrey Hutzelman
- Re: [mif] [dhcwg] [dnsext] [DNSOP] 2nd Last Call … Jeffrey Hutzelman
- Re: [mif] [dhcwg] [dnsext] [DNSOP] 2nd Last Call … Jeffrey Hutzelman
- Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF … Ted Lemon
- Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF … Doug Barton
- Re: [mif] 2nd Last Call for MIF DNS server select… teemu.savolainen