BIND8's useless messages
Gregory Neil Shapiro
gshapiro at sendmail.org
Wed Jul 19 00:16:13 UTC 2000
-----BEGIN PGP SIGNED MESSAGE-----
andris> 3. Sendmail initially issues a query of record-type ANY which
andris> causes the retrieval of the bad SOA RR. Sendmail notices
andris> the rejected query and (re-)queues the message. Delivery
andris> ultimately fails if the the remote site's DNS is not fixed
andris> before the queue timeout interval is reached.
First, and foremost, sendmail *only* uses T_ANY for canonification
(dns_getcanonname()), *not* for delivery (MX retrieval) (getmxrr()).
However, even the above scenario doesn't break canonification:
ret = res_querydomain(host, *dp, C_IN, qtype,
If it is rejected, ret < 0...
if (ret <= 0)
if (errno == ECONNREFUSED || h_errno == TRY_AGAIN)
if (h_errno != HOST_NOT_FOUND)
/* might have another type of interest */
if (qtype == T_ANY)
# if NETINET6
qtype = T_AAAA;
# else /* NETINET6 */
qtype = T_A;
# endif /* NETINET6 */
As you can see, unless the h_errno is HOST_NOT_FOUND (which it will not be
in your scenario), we do indeed try individual AAAA, A, and MX lookups.
andris> I haven't tested this, but sendmail's insistence on using the
andris> ANY query is alleged to also make it vulnerable to ignoring MX
andris> RRs under the following scenario:
andris> @ 8H IN A 184.108.40.206
andris> 4H IN MX 5 mailhost
andris> mailhost 8H IN A 220.127.116.11
andris> If the A RRs are still cached after the MX RR has expired,
andris> sendmail will (allegedly) attempt delivery to 18.104.22.168 instead
andris> of 22.214.171.124.
Again, we go to deliver, we do not do a T_ANY lookup. Look at getmxrr()
and you will see all is well.
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Comment: Processed by Mailcrypt 3.5.5, an Emacs/PGP interface
-----END PGP SIGNATURE-----
More information about the bind-workers