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

<> Thu, 20 October 2011 07:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1135121F85A1; Thu, 20 Oct 2011 00:01:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.578
X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4+0TEhUqtys6; Thu, 20 Oct 2011 00:01:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3320621F8593; Thu, 20 Oct 2011 00:01:35 -0700 (PDT)
Received: from ( []) by (Switch-3.4.4/Switch-3.4.3) with ESMTP id p9K71K4Z007935; Thu, 20 Oct 2011 10:01:29 +0300
Received: from ([]) by over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Oct 2011 10:01:20 +0300
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 20 Oct 2011 09:01:18 +0200
Received: from ([]) by ([]) with mapi id 14.01.0339.002; Thu, 20 Oct 2011 09:01:18 +0200
Thread-Topic: [dnsext] [mif] 2nd Last Call for MIF DNS server selection document
Thread-Index: AQHMjlOod32iNq3Hr0aVNz752afFi5WEy7FQ
Date: Thu, 20 Oct 2011 07:01:17 +0000
Message-ID: <>
References: <COL118-W55403198A984BAAE44BA47B1F70@phx.gbl> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Company Confidential; Project=None;
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IvQmQ0o/K2jquxqC2Uue5GHpzEuo3S9zNfeh3beuXC4d4U+9SoG2zegA7qMLdX6PTG17IL7pxR5S/KY/iCJNnn1c5UqLju8bmTWbhVRC5KYyRvx6Lux+omb+cjLr4ZT4xGr6EYlMoJAb4mKk7Ygo2IOCLEfvotq8eZrg90l9H1dML3IGXW5CR0VaroyKyJb6YmetiFAenF/tDgR293RVPdnMoKPAurwSeBTTqO8uNr6TcXVEvm613p4YTVwzPTjUYrSShwM2n81B2EdPx398YIM=
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_000B_01CC8F0F.35163130"
MIME-Version: 1.0
X-OriginalArrivalTime: 20 Oct 2011 07:01:20.0574 (UTC) FILETIME=[123935E0:01CC8EF6]
X-Nokia-AV: Clean
Subject: Re: [mif] [dnsext] 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: Thu, 20 Oct 2011 07:01:37 -0000

Hi Ray,

> -----Original Message-----
> From: ext Ray Bellis []
> Sent: 19. lokakuuta 2011 13:40
> To: Savolainen Teemu (Nokia-CTO/Tampere)
> Cc: <>; <>; <>;
> <>; <>; <>;
> <>
> 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-
> 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
> 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
> I'd like to hear the authors' thoughts on these.  I'm not sure that this
> 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

   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,