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@xxxxxxxxx On Fri, Feb 15, 2013 at 7:48 PM, Joe Touch <touch@xxxxxxx> wrote: > > > On 2/15/2013 3:17 PM, John C Klensin wrote: >> >> >> >> --On Friday, February 15, 2013 14:10 -0800 Joe Touch >> <touch@xxxxxxx> 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