Re: Services and top-level DNS names (was: Re: Update of RFC 2606

Bill Manning <bmanning@ISI.EDU> Tue, 08 July 2008 11:29 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 6E0E43A69D7; Tue, 8 Jul 2008 04:29:29 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D0673A6A35 for <>; Tue, 8 Jul 2008 04:29:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[AWL=0.849, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2MV08RiwBmrc for <>; Tue, 8 Jul 2008 04:29:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8AB453A69D7 for <>; Tue, 8 Jul 2008 04:29:24 -0700 (PDT)
Received: from (localhost []) by (8.13.8/8.13.8) with ESMTP id m68BSf0A003101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Jul 2008 04:28:42 -0700 (PDT)
Received: (from bmanning@localhost) by (8.13.8/8.13.8/Submit) id m68BSd0v003082; Tue, 8 Jul 2008 04:28:39 -0700 (PDT)
Date: Tue, 8 Jul 2008 04:28:39 -0700
From: Bill Manning <bmanning@ISI.EDU>
To: John C Klensin <>
Subject: Re: Services and top-level DNS names (was: Re: Update of RFC 2606
Message-ID: <>
References: <> <41C0AA5BE72A51344F410D1E@p3.JCK.COM> <> <A886A120D781BDBC027B4BFF@p3.JCK.COM>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <A886A120D781BDBC027B4BFF@p3.JCK.COM>
User-Agent: Mutt/
X-ISI-4-43-8-MailScanner: Found to be clean
Cc: Mark Andrews <>,, Bill Manning <bmanning@ISI.EDU>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

On Tue, Jul 08, 2008 at 01:49:24AM -0400, John C Klensin wrote:
> --On Monday, 07 July, 2008 12:08 -0700 Bill Manning
> <bmanning@ISI.EDU> wrote:
> > 	John, do you beleive that DNS host semantics/encoding that
> > form the bulk 	of the IDN work (stringprep, puny-code,
> > are applicable -only- in 	the context of zone file generation
> > or are they also applicable in  	configuration and acess
> > control for DNS?
> I think I don't understand the question.   RFC 3490 tries to
> make a distinction between IDNA-aware and IDNA-unaware
> applications and domain name "slots".  The intent is, more or
> less, to permit a punycode-encoded string with the prefix (which
> the IDNA2008 drafts call an "A-label") to appear nearly anywhere
> in the DNS but to expect conversion to and/or from native
> characters only in contexts where IDNA is explicitly applied.
> Even in zone files, IDNA is generally applicable only to labels
> and not to data fields.
> > 	path/alias expansion/evaluation will be interesting if "." is
> > not what 	7bit ASCII thinks of as "."
> RFC 3490 lists a series of other characters that are to be
> treated as label-separating dots if encountered in an IDNA
> context.  That model causes a number of interesting problems in
> contexts where one has to recognize a string as a domain name,
> and possibly process it, without knowing anything about IDNA.
> The problems show up in situations as simple as conversions
> between label-dot-label-dot-label format and length-label list
> format, making it very important whether one identifies an FQDN
> as containing IDNA labels or converts it to length-label form
> first.  IDNA2008 (see the IDNABIS WG and its documents and
> mailing list) does away with all of this as part of a general
> plan to do a lot less mapping of characters into other
> characters.  So, for the proposed newer version the only
> label-separating dot permitted in the protocol is the character
> you know as 7bit ASCII "." (U+002E in Unicode-speak).
> Does that answer whatever the question was intended to be?
>    john

perhaps - let me try again w/ example.

in my resolv.conf file, I have the following three lines:

search .
nameserver 2001:478:6:0:230:48ff:fe22:6a29

the line of interest is the first line, starting w/ search.
the expectation is that the items on this list are domain names.
in my case, they are all "fully qualified".   since this is a 
configuration file - not a zone file, is IDNA2008 expected to 
apply?  this data is not, per se, in the DNS.


Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

Ietf mailing list