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: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E0E43A69D7; Tue, 8 Jul 2008 04:29:29 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D0673A6A35 for <ietf@core3.amsl.com>; Tue, 8 Jul 2008 04:29:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[AWL=0.849, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MV08RiwBmrc for <ietf@core3.amsl.com>; Tue, 8 Jul 2008 04:29:24 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 8AB453A69D7 for <ietf@ietf.org>; Tue, 8 Jul 2008 04:29:24 -0700 (PDT)
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (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 boreas.isi.edu (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 <john-ietf@jck.com>
Subject: Re: Services and top-level DNS names (was: Re: Update of RFC 2606
Message-ID: <20080708112839.GA27831@boreas.isi.edu>
References: <200807070030.m670UIR1073241@drugs.dv.isc.org> <41C0AA5BE72A51344F410D1E@p3.JCK.COM> <20080707190831.GA26531@boreas.isi.edu> <A886A120D781BDBC027B4BFF@p3.JCK.COM>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <A886A120D781BDBC027B4BFF@p3.JCK.COM>
User-Agent: Mutt/1.4.2.2i
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: bmanning@boreas.isi.edu
Cc: Mark Andrews <Mark_Andrews@isc.org>, ietf@ietf.org, Bill Manning <bmanning@ISI.EDU>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

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, et.al.)
> > 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 . karoshi.com. ip4.int. ep.net.
nameserver 198.32.2.10
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.



-- 
--bill

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