BIND8's useless messages

Andris Kalnozols andris at
Wed Jul 19 02:42:46 UTC 2000

> Andris Kalnozols <andris at> wrote:
> >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.
> At present, I don't have a way of testing the above scenario.  It
> looks unlikely.  I have not seen evidence of this occuring.

Here's a live example of the above scenario running sendmail
version 8.9.3 and BIND 8.2.2-P5:

  hplms26# sendmail -v

  Running SAA22046 (sequence 1 of 1)
  administrator at
    Name server time out
  administrator at Transient parse error --
    message queued for future delivery

  Jul 18 10:48:00 hplms26 named[24978]: Malformed response from
      [].53 (out of data in final pass)
  Jul 18 10:48:00 hplms26 named[24978]: mail name "administrator"
      (owner "") IN (response from [])
      is invalid - rejecting

Note that BIND option "check-names response fail" is enabled.
The zone contents:

  @            1H IN SOA administrator. (
                               16              ; serial
                               15M             ; refresh
                               10M             ; retry
                               1D              ; expiry
                               1H )            ; minimum

               1H IN NS
               1H IN MX        10
com2           1H IN A
pop3           1H IN A
www            1H IN A

After reconfiguring BIND to "check-names response warn", sendmail
is able to deliver the message:

  hplms26# sendmail -v

  Running SAA22046 (sequence 1 of 1)
  administrator at
    Connecting to via esmtp...
  220 ****************************************************
  >>> EHLO
  500 Command not recognized.
  >>> HELO
  250 OK
  >>> MAIL From:<andris at>
  250 OK - mail from <andris at>
  >>> RCPT To:<administrator at>
  250 OK - Recipient <administrator at>
  >>> DATA
  354 Send data.  End with CRLF.CRLF
  >>> .
  250 OK
  administrator at Sent (OK)
  Closing connection to
  >>> QUIT
  221 closing connection

According to the 8.10.0 Release Notes:

   If a resolver ANY query is larger than the UDP packet size, the
           resolver will fall back to TCP.  However, some
           misconfigured firewalls black 53/TCP so the ANY lookup
           fails whereas an MX or A record might succeed.  Therefore,
           don't fail on ANY queries.

Is it reasonable to assume that this fix would also solve the problem
just demonstrated?

> Note that the initial query for ANY is only done for hostname
> canonification.

As I found out a bit too late, someone's previous post to this thread
implied that the "query for ANY" theme has seen its share of controversy
in sendmail-related discussions. ;-(
I have no axe to grind either way but was just repeating the opinion
of someone whose knowledge I respect.


More information about the bind-workers mailing list