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

Keith Moore <moore@network-heretics.com> Fri, 21 October 2011 01:08 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 A74E911E8099; Thu, 20 Oct 2011 18:08:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.807
X-Spam-Level:
X-Spam-Status: No, score=-3.807 tagged_above=-999 required=5 tests=[AWL=-0.208, 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 sAAg6U9lEK09; Thu, 20 Oct 2011 18:08:10 -0700 (PDT)
Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id B0DC811E8091; Thu, 20 Oct 2011 18:08:10 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id CD42F21172; Thu, 20 Oct 2011 21:08:09 -0400 (EDT)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute3.internal (MEProxy); Thu, 20 Oct 2011 21:08:09 -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=qHOj5RVNbeLDBZ3kqQ9hlPRTsH8=; b=nx nXShspT+8/SvrDB8r/9XbhQAzGq0Y1VDp6pdUPzAptbhklkFQeg1AN3F/BlJpCG6 FKBQ7DfHYiWKySxY/r/EIHHdfeJ/SWHrYBNnZJBvmcY2AGRdz+C/2bQV4G/SMGQZ 5l9mqRGunAXTbg6+eC+9SFtGxtCC4QyGDNYPbOqbw=
X-Sasl-enc: oPXSpLq6gHGfeqDCFDuJw/Y+OPTvaTI+76jYhQAU+cxB 1319159289
Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id B0A5F4833E7; Thu, 20 Oct 2011 21:08:07 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: Keith Moore <moore@network-heretics.com>
In-Reply-To: <4EA09791.8010705@gmail.com>
Date: Thu, 20 Oct 2011 21:07:41 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <C8398996-79B5-437E-82A5-6B869ECF8F4E@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>
To: Brian E Carpenter <brian.e.carpenter@gmail.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 01:08:11 -0000

It might that IETF should consider "bare names" out of its scope, except perhaps to say that they're not DNS names, they don't have to necessarily be mappable to DNS names, and that their use and behavior is host and application-dependent.

Keith

On Oct 20, 2011, at 5:50 PM, Brian E Carpenter wrote:

> 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 mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif