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

[Bill Manning <[e-mail]>]

On Tue, Jul 08, 2008 at 01:49:24AM -0400, John C Klensin wrote:
> 
> 
> --On Monday, 07 July, 2008 12:08 -0700 Bill Manning
> <[e-mail]> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf