ietf
[Top] [All Lists]

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

2008-07-08 06:33:04


--On Tuesday, 08 July, 2008 04:28 -0700 Bill Manning
<bmanning(_at_)ISI(_dot_)EDU> 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
<bmanning(_at_)ISI(_dot_)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.

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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>