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

[John C Klensin <[e-mail]>]

--On Tuesday, 08 July, 2008 04:28 -0700 Bill Manning
<[e-mail]> wrote:

> 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.

Nothing in IDNA2008 makes it apply.  Nothing in IDNA2008 even
makes it apply to zone files (!).   My personal view --others in
the WG might have other opinions-- is that one would be better
off using A-labels (the punycode-encoded forms) in this sort of
context.

The reasoning involves two points:

	* While I don't imagine you would put domain names in
	your search rules that you couldn't render (or easily
	type) on your machine, I believe that will happen with
	some servers who are supporting multilingual
	communities.  The A-labels can be typed and rendered
	accurately on any system that can handle construction of
	the config file (with its ASCII keywords) itself.  The
	U-labels put you at some risk of seeing little boxes or
	question marks (or, in some cases, worse) as well as
	potentially being hard to type.
	
	* An explicit design goal for IDNA (both versions) is to
	avoid changing the DNS or low-level DNS implementations.
	The search rule interpreter in your resolver is going to
	have to substitute names in that can be used in the DNS
	and those are the A-labels.  Putting U-labels in the
	config file would requires that the resolver be
	IDNA-aware, understand those labels, and map them to the
	A-label form before doing lookups.  It would also
	presumably require doing that every time the config file
	is read, a small decrement in efficiency.

Now, to give you a slightly different answer, I sort of expect
that communities who use IDNs a lot, especially those for whom
typing ASCII is uncomfortable, will find that IDNs drive them
toward "compilers" or special user interfaces to aid them in
producing all sorts of config files.  I'd expect them to develop
tools to permit constructing zone file and resolver config file
templates with IDN U-labels in them and then translating them
into DNS-internal forms (i.e., with the A-labels).  I'd even
expect such tools to provide screen interfaces that permit
working with the keywords of the config files without having to
type them out (a process that gets error-prone if words like
"search" or "nameserver" or "$ORIGIN" are not familiar and/or
the keys to enter them aren't on the keyboard).

But those are local tools, not part of anyone's protocol or
global facilities.

Again, just IMO.

   john





_______________________________________________
Ietf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf