BIND8's useless messages
andris at hpl.hp.com
Tue Jul 18 05:55:04 UTC 2000
> On Jul 17, 9:31pm, Andrew Brown wrote:
> } Subject: Re: BIND8's useless messages
> } i would like to point out that sendmail (as an example of a
> } widely used mta) doesn't necessarily do gethostbyname(), particularly
> } since it needs the mx records which *aren't* returned by
> } gethostbyname().
On July 17, Don Lewis then wrote:
> Sendmail does an MX lookup and then calls gethostbyname() on the host
> names contained in the MX RRs. Sendmail ignores any A RRs contained
> in the additional data section of the response to its MX query, so it's
> not a fatal problem if an address are missing because the MX pointed to
> a CNAME because gethostbyname() will follow the CNAME and find the A RR.
> when sendmail looks up the IP address for each MX.
Just as an FYI, here's a scenario where sendmail's resolution process
results in less-than-robust mail delivery:
1. Sendmail uses a nameserver configured with the option
'check-names response fail'.
2. Mail is addressed to a domain with illegal data, typically a
a malformed RDATA field in the SOA RR such as
'administrator.' or 'user\@domain'. As certain non-BIND
nameservers proliferate on the Internet, we're noticing
an increasing number of these :-(
3. Sendmail initially issues a query of record-type ANY which
causes the retrieval of the bad SOA RR. Sendmail notices
the rejected query and (re-)queues the message. Delivery
ultimately fails if the the remote site's DNS is not fixed
before the queue timeout interval is reached.
I haven't tested this, but sendmail's insistence on using the
ANY query is alleged to also make it vulnerable to ignoring MX
RRs under the following scenario:
@ 8H IN A 126.96.36.199
4H IN MX 5 mailhost
mailhost 8H IN A 188.8.131.52
If the A RRs are still cached after the MX RR has expired,
sendmail will (allegedly) attempt delivery to 184.108.40.206 instead
LaMont informs me that Postfix is not vulnerable to either of
More information about the bind-workers