BIND8's useless messages

[Andris Kalnozols]

> Andris Kalnozols <andris at hpl.hp.com> 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 -qRstudentambassadors.org -v

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

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

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

  $ORIGIN studentambassadors.org.
  @            1H IN SOA       com2.ambassadors.com. administrator. (
                               16              ; serial
                               15M             ; refresh
                               10M             ; retry
                               1D              ; expiry
                               1H )            ; minimum

               1H IN NS        com2.ambassadors.com.
               1H IN MX        10 pop3.ambassadors.com.
com2           1H IN A         207.108.60.131
pop3           1H IN A         207.108.60.131
www            1H IN A         207.108.60.134

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

  hplms26# sendmail -qRstudentambassadors.org -v

  Running SAA22046 (sequence 1 of 1)
  administrator at studentambassadors.org...
    Connecting to pop3.ambassadors.com. via esmtp...
  220 ****************************************************
  >>> EHLO hplms26.hpl.hp.com
  500 Command not recognized.
  >>> HELO hplms26.hpl.hp.com
  250 OK
  >>> MAIL From:<andris at hplms26.hpl.hp.com>
  250 OK - mail from <andris at hplms26.hpl.hp.com>
  >>> RCPT To:<administrator at studentambassadors.org>
  250 OK - Recipient <administrator at studentambassadors.org>
  >>> DATA
  354 Send data.  End with CRLF.CRLF
  >>> .
  250 OK
  administrator at studentambassadors.org... Sent (OK)
  Closing connection to pop3.ambassadors.com.
  >>> 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.

Andy