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). A primer from the dns terminology draft:
Host name: This term and its equivalent, "hostname", have been
widely used but are not defined in [RFC1034], [RFC1035],
[RFC1123], or [RFC2181]. The DNS was originally deployed into the
Host Tables environment as outlined in [RFC0952], and it is likely
that the term followed informally from the definition there. Over
time, the definition seems to have shifted. "Host name" is often
meant to be a domain name that follows the rules in Section 3.5 of
[RFC1034], the "preferred name syntax". Note that any label in a
domain name can contain any octet value; hostnames are generally
considered to be domain names where every label follows the rules
in the "preferred name syntax", with the amendment that labels can
start with ASCII digits (this amendment comes from Section 2.1 of
[RFC1123]).
And RFC-1123 states:
2.1 Host Names and Numbers
The syntax of a legal Internet host name was specified in RFC-952
[DNS:4]. One aspect of host name syntax is hereby changed: the
restriction on the first character is relaxed to allow either a
letter or a digit. Host software MUST support this more liberal
syntax.
Host software MUST handle host names of up to 63 characters and
SHOULD handle host names of up to 255 characters.
RFC-1101 Section-3.1 states:
The current syntax for network names, as defined by [RFC 952] is an
alphanumeric string of up to 24 characters, which begins with an
alpha, and may include "." and "-" except as first and last
characters. This is the format which was also used for host names
before the DNS.
So based on these references, do you believe the following are legal
DNS entries:
münchen._openpgpkey.nohats.ca. IN OPENPGPKEY MAo=
jon..smiths._openpgpkey.nohats.ca. IN OPENPGPKEY MAo=
jon\.smiths._openpgpkey.nohats.ca. IN OPENPGPKEY MAo=
jon\\smiths._openpgpkey.nohats.ca. IN OPENPGPKEY MAo=
jon*smiths._openpgpkey.nohats.ca. IN OPENPGPKEY MAo=
42._openpgpkey.nohats.ca. IN OPENPGPKEY MAo=
-paul-._openpgpkey.nohats.ca. IN OPENPGPKEY MAo=
1111111111222222222233333333334444444444555555555566666666661234._openpgpkey.nohats.ca.
IN OPENPGPKEY MAo=
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa._openpgpkey.nohats.ca.
IN OPENPGPKEY MAo=
lines---lines._openpgpkey.nohats.ca. IN OPENPGPKEY MAo=
😱 ._openpgpkey.nohats.ca. IN OPENPGPKEY MAo=
Let's see what the tools say:
$ named-checkzone nohats.ca nohats.ca
nohats.ca:22: using RFC1035 TTL semantics
dns_master_load: nohats.ca:210: empty label
dns_master_load: nohats.ca:213: label too long
dns_master_load: nohats.ca:214: label too long
nohats.ca:216: unknown RR type '._openpgpkey.nohats.ca.'
zone nohats.ca/IN: loading from master file nohats.ca failed: empty
label
zone nohats.ca/IN: not loaded due to errors.
$ ldns-read-zone nohats.ca
Syntax error, could not parse the RR's rdata at 203
$ validns nohats.ca
nohats.ca:170: record name is not valid
nohats.ca:205: record name is not valid
nohats.ca:206: invalid or unsupported rdtype openpgpkey
nohats.ca:207: record name is not valid
nohats.ca:208: invalid or unsupported rdtype openpgpkey
nohats.ca:209: invalid or unsupported rdtype openpgpkey
nohats.ca:210: invalid or unsupported rdtype openpgpkey
nohats.ca:211: invalid or unsupported rdtype openpgpkey
nohats.ca:212: record name expected
Furthermore, as DNS is case sensitive you would have the problem of
jonsmiths._openpgpkey.nohats.ca. IN OPENPGPKEY <blob1>
JonSmiths._openpgpkey.nohats.ca. IN OPENPGPKEY <blob2>
which would be the same DNS label in DNS.
Therefor, I stand by the first line in section 3.1 of the draft
that you believe is false:
The DNS does not allow the use of all characters that are supported
in the "local-part" of email addresses as defined in [RFC5322] and
[RFC6530].
And in fact, I'd say email addresses with local-parts of > 63
characters are in fact more likely that case-sensitive local-part
delivery to different users.
largely because
of the same "no one but the delivery server interprets" rules
that John and I have cited several times), using it directly is
the most obvious solution, obvious to the point that, IMO, you
need to justify anything else.
Note that as document author, I stated my preference was for hashed
lowercse lookup but I would be okay with the base32 split solution. The
consensus the chair posted to the list was to use hashes without
lowercasing.
My own IETF LC comment was that I think the document should address the
issue of different case by either adding a lowercase or a second lookup
(neither of which is 'guessing')
Paul