BIND8's useless messages

Andris Kalnozols 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    1.2.3.4
            4H IN MX   5  mailhost
  mailhost  8H IN A    1.2.3.9

If the A RRs are still cached after the MX RR has expired,
sendmail will (allegedly) attempt delivery to 1.2.3.4 instead
of 1.2.3.9.

LaMont informs me that Postfix is not vulnerable to either of
these scenarios.

Andy



More information about the bind-workers mailing list