Greg Owen <[EMAIL PROTECTED]> writes:
>> Everytime a user sends a message to aol.com, I get [...]
>> deferral: CNAME_lookup_failed_temporarily._(#4.4.3)/
>> Is there an easy way to get around this?
> Yup, search the archives for "oversized DNS" and check out the patch on
> www.qmail.org described as:
> "Chuck Foster has a patch which works on both qmail's dns.c and tcpserver's
> dns.c which make them work with oversize DNS packets."
> There's another patch which does something similar, but I believe it's
> mentioned in the archives and not on the qmail page.
There are, AFAIK, three patches that fix this bug.
1. Just bump the packet buffer size up to 65536.
Works with recent BIND resolver libraries, which will automatically
do a TCP query within the library code if the reply comes back with
the truncation bit set. This is the simplest fix, though it's also
the most wasteful of memory (and/or swap space allocation, depending
on how your system does copy-on-write and its page size and so on).
2. Chuck Foster's patch <URL:http://www.qmail.org/big-dns-patch>.
This patch dynamically reallocates the buffer based on the size
returned by the resolver library (repeating as necessary to make
it big enough). This also requires resolver libraries that do the
TCP retry, and might have problems if the resolver code returns
the number of bytes placed in the buffer instead of the number of
bytes in the full response (though I've never seen this behavior,
I vaguely recall someone saying they'd seen it).
3. My patch <URL:http://www.ckdhr.com/ckd/qmail-103.patch>.
This is an adaptation of Chuck Foster's patch (see #2) which should
work with any resolver library, no matter how old, and uses a guard
byte to avoid the "number of bytes placed in the buffer" library
bug. It reallocates only once, to 65536, rather than just to the
size needed, so it can be less memory-efficient than Chuck's patch
(though like his patch it only reallocates if the response is larger
than PACKETSZ, which defaults to 512 bytes). After reallocating, it
forces a TCP query, rather than requiring the resolver library to do
so (avoiding an extra round-trip between qmail and the name server,
though if they're on the same machine or local network this is not a
big worry).
Since last time this question came up (also regarding AOL), there was a
question as to why some people didn't have trouble reaching it, I would
also like to explain that. Basically, depending on the timing and
ordering of queries made to your local nameserver, the size of the
response to an ANY query for "aol.com" may be larger than the 512 byte
limit of a UDP packet, or it may not.
"May not" is likely to happen if the A and MX records time out but the
NS records don't; since the .COM servers set a 2 day TTL on those but
AOL sets a 1 hour TTL on their records, this will often happen on lower
traffic nameservers. Higher traffic nameservers are more likely to
have those records in cache at any given time, frustrating an unpatched
qmail's attempts to check for CNAMEs.
A better test is to send mail to <[EMAIL PROTECTED]>; if it
clears your queue and winds up bouncing from here, your MTA can send
mail to hosts with MX lists that exceed 512 bytes. (By using a single
RRset with a single TTL that exceeds 512 bytes, the problem can be seen
without depending on the timing and ordering of other queries.)
--
Christopher Davis * <[EMAIL PROTECTED]> * <URL:http://www.ckdhr.com/ckd/>
Put location information in your DNS! <URL:http://www.ckdhr.com/dns-loc/>
