<html><head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000"><br>
<br>
Bob Harold wrote:
<blockquote
cite="mid:CA+nkc8BW=svzNZFxTaAXReGg3eBDFbtCN6V3TiS_XvBaRX1a4w@mail.gmail.com"
type="cite">
<div dir="ltr">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:<div>
<br><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div>check-names
applies to the owner names of A, AAAA and MX records. It also applies
to the</div></div><div><div>domain names in the RDATA of NS, SOA, MX,
and SRV records. It also applies to the RDATA of</div>
</div><div><div>PTR records where the owner name indicated that it is a
reverse lookup of a hostname (the owner</div></div><div><div>name ends
in IN-ADDR.ARPA, IP6.ARPA, or <a moz-do-not-send="true"
href="http://IP6.INT">IP6.INT</a>).</div></div></blockquote><div><div><br></div><div
class="gmail_extra">I had always thought that it applied to all
records. My apologies. I wonder if it always made that distinction?</div></div></div></div>
</blockquote>
<br>
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@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.<br>
<br>
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.<br>
<br>
vixie<br>
</body></html>