Mark Martinec | 6 Sep 18:25 2007

reopening(?) - retry with TCP after receiving truncated UDP replies

I noticed the following bug is closed:

  [1761488] libar: retry with TCP after receiving truncated UDP replies

yet the dkim-milter 2.2.0 still has problems with UDP DNS replies
with a TC bit set, even though the requested RR is present in the
reply (but the gratuitous authoritative section is truncated).
As far as I can see from a tcpdump, no TCP DNS query is attempted.

This is a standard install (which in other respects works nicely)
from ports on FreeBSD 6.2. As far as I can tell it does use async
resolving library that comes with dkim-milter.

Mail is tempfailed unless I include option: -C int=a

Log tells:

Sep  6 17:54:33 sss sm-mta[18516]: l86FsWtx018516:
  from=<xxx@...>, size=1400, class=0, nrcpts=1,
  msgid=<123@...>, bodytype=7BIT, proto=ESMTP,
  daemon=IPv6, relay=xxx [IPv6:xxx]

Sep  6 17:54:33 sss dkim-filter[18243]: l86FsWtx018516:
  dkim_eoh(): internal error from libdkim:
  `' reply truncated

(the problem is not specific to IPv6, and not specific to sendmail,
the same happens on another host where resolver is on IPv4, with Postfix).

Here is the message, so one can test verification at will:

The message verifies just fine with Mail::DKIM.

I know the public key is long, it was set to 1872 bits on purpose,
as the RR just fits into a 512 byte limit but the optional DNS reply
sections need to be trimmed by a DNS server.

I see the following problems here:

 * the '-C dns=a' doesn't apply even though it is a dns-type
   of a problem, one needs to set: '-C int=a';

 * tcp retry of a DNS query does not happen;

 * the complete requested RR _is_ included in a response,
   so according do DNS rfc the client is permitted to use it
   if it choses to do so, despide TC flag being set;


This email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>