In message <20150911212549.61594.qmail@xxxxxxx>, "John Levine" writes:
> In article <alpine.LFD.2.20.1509111502500.29138@xxxxxxxxxxxxxx> you write:
> >On Fri, 11 Sep 2015, John C Klensin wrote:
> >
> >>> So you are claiming that DNS can take any UTF-8 character?
> >
> >> base of DNS servers did not handle well. But there was never a
> >> claim that the DNS couldn't store characters coded in UTF-8 or,
> >> for that matter, any bit sequence in octets. The latter
> >> capability is made quite clear in the DNS base documents
> >> (1034/1035) and RFC 2181.
> >
> >We are not talking about the RDATA part - we are talking about the DNS
> >label (aka hostname or qname). ...
>
> Hold it. Every hostname is a DNS name, but most possible DNS names
> are not hostnames. To take an obvious example, none of the names that
> this draft specifies for the names of PGP keys are hostnames, because
> hostnames are limited to ASCII letters, digits, and hyphens, and the
> key names all contain underscores.
>
> Since they're not hostnames, I agree with John K that there is no
> reason to limit the representation of a local-part to hostname
> characters. Names in the DNS really can be arbitrary octets, up to 63
> octets per component, and the DNS handles them completely
> transparently (other than the rule to fold ASCII upper and lower case
> letters.) If you put UTF-8 names directly into the DNS, your master
> file would be kind of ugly but it would work fine. I've done it.
And the DNS is supposed to preserve the case of entered labels.
RFC 1034
"By convention, domain names can be stored with arbitrary case, but
domain name comparisons for all present domain functions are done in a
case-insensitive manner, assuming an ASCII character set, and a high
order zero bit. This means that you are free to create a node with
label "A" or a node with label "a", but not both as brothers; you could
refer to either using "a" or "A". When you receive a domain name or
label, you should preserve its case. The rationale for this choice is
that we may someday need to add full binary domain names for new
services; existing services would not be changed."
Later versions of BIND 9 do that to the RRset level and it would
be possible to do it to the RR level if needed. It is theoretically
possible to distingish between JoeSmith and joesmith if preservation
to the RR level is done for arbitary DNS data. You would get back
all data and the client would need to check the case of the owner
names if the owner name is supposed to be case sensitive and only
use those that match.
However for OpenPGP you don't need case preservation in the DNS at
all as the key blob contains the original case. If the MUA is not
checking this in the key blob it is broken.
Most but not all clients correctly cope with a different casing
being returned to that of the question in the answer section. It
is up to the client to know if what they lookup is case sensitive
or not. Some of them don't treat hostnames case insensitively when
looking for responses hence the acl below.
4079. [func] Preserve the case of the owner name of records to
the RRset level. [RT #37442]
3731. [func] Added a "no-case-compress" ACL, which causes
named to use case-insensitive compression
(disabling change #3645) for specified
clients. (This is useful when dealing
with broken client implementations that
use case-sensitive name comparisons,
rejecting responses that fail to match the
capitalization of the query that was sent.)
[RT #35300]
3645. [protocol] Use case sensitive compression when responding to
queries. [RT #34737]
3007. [bug] Named failed to preserve the case of domain names in
rdata which is not compressible when writing master
files. [RT #22863]
2855. [func] nsupdate will now preserve the entered case of domain
names in update requests it sends. [RT #20928]
2236. [bug] dnssec-signzone failed to preserve the case of
of wildcard owner names. [RT #17085]
1811. [func] Preserve the case of domain names in rdata during
zone transfers. [RT #13547]
> R's,
> John
>
> PS: It's dismaying to see confusion about basic DNS concepts at such a
> late point.
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx