[dns-operations] about the underline in hostname

[Paul Vixie]

Bob Harold wrote:
> Thanks to everyone that answered.  I did not realize that
> "check-names" only checked things it considered "hostnames" and not
> all DNS names.  I just reread the BIND manual and found:
>
>     check-names applies to the owner names of A, AAAA and MX records.
>     It also applies to the
>     domain names in the RDATA of NS, SOA, MX, and SRV records. It also
>     applies to the RDATA of
>     PTR records where the owner name indicated that it is a reverse
>     lookup of a hostname (the owner
>     name ends in IN-ADDR.ARPA, IP6.ARPA, or IP6.INT <http://IP6.INT>).
>
>
> I had always thought that it applied to all records.  My apologies.  I
> wonder if it always made that distinction?

yes. this has been true as long ago as bind 4.9. the only reason bind
cares what a host name looks like is because of a vulnerability reported
in sendmail back in the mid 1990's, where a unix newline character (\n
in C) could be embedded in a PTR RDATA to violate framing in a sendmail
"qf" file. barb at CERT asked me to fix this in the resolver (stub and
recursive) since that was an easier internet-wide patch than fixing
sendmail. i mistakenly said "yes" and then set about deciding whether \n
was the only character PTR RDATA could not contain, and whether PTR
RDATA was the only context in which the rules for a "host name" should
be applied.

i should have said "no" and let sendmail fend for itself. these "host
name rules" have been an endless source of drama and i'm glad that no
other resolver (stub  or caching) enforces them. because of BIND's own
long-tail problem, there's no way to get this logic out of the internet
at this point, but i'd still love to see ISC try, by removing it from
BIND itself. to me this logic is as broken as a home-CPE device that
won't allow EDNS because it thinks it knows what UDP/53 messages have to
look like. it's an unfortunate constraint, applied in ignorance, and has
caused more harm than good.

vixie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20140529/67cf5309/attachment.html>