Let's see, here is the list of RFCs that the RFC Editor believes
update RFC 1035:
RFC 1101, RFC 1183, RFC 1348, RFC 1876, RFC 1982, RFC 1995, RFC 1996,
RFC 2065, RFC 2136, RFC 2181, RFC 2137, RFC 2308, RFC 2535, RFC 2845,
RFC 3425, RFC 3658, RFC 4033, RFC 4034, RFC 4035, RFC 4343, RFC 5936,
RFC 5966, RFC 6604,
Thanks,
Donald
=============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e3e3(_at_)gmail(_dot_)com
On Fri, Feb 15, 2013 at 7:48 PM, Joe Touch <touch(_at_)isi(_dot_)edu> wrote:
On 2/15/2013 3:17 PM, John C Klensin wrote:
--On Friday, February 15, 2013 14:10 -0800 Joe Touch
<touch(_at_)isi(_dot_)edu> wrote:
Let's just say that there doesn't appear to be disagreement
that the DNS can handle a-z/0-9/'-'.
Other values _may or may not_ be permitted or handled opaquely
in the lookup, AFAICT. It remains a question AFAICT.
Joe,
Except for IDNs (or labels starting with "xn--" more
specifically), for which there are special rules, it appears to
me that the spec is _extremely_ clear that a lookup operation
that fails to deal with those "other values" in labels
--including even properly-escaped embedded "." characters -- is
unambiguously non-conforming.
Seems clear to me:
RFC1035:
The labels must follow the rules for ARPANET host names. They must
start with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen. There are also some
restrictions on the length. Labels must be 63 characters or less.
--
If any label were allowed, then why does IDN conversion go so far out of its
way to exclude particular strings, e.g., those beginning/ending with '-' and
encodes everything 0..7F into a-z/0-9?
(I was focused on looking up A records given FQDNs)
Joe