Steve Linberg <[EMAIL PROTECTED]> writes:
> So if this is proof that the large-DNS patch is in, something else is
> wrong, because my logs are full of these:
> ==============================================================
> Sep 2 10:26:25 shagrat qmail: 999440785.468162 delivery
> 60258: deferral: CNAME_lookup_failed_temporarily._(#4.4.3)/
> ==============================================================
> ...for mail sent to msn.com addresses.
> Ack. So... I'm totally confused.
It's not the buffer size problem. It's a problem that, because of the
way qmail does DNS queries and error reporting, looks exactly *like* the
buffer size problem, but isn't. :)
qmail does an ANY query for the name you're sending mail to when
canonicalizing, in order to deal with a bug in versions of BIND
pre-4.9.4 (which all have other, larger bugs--like security
holes--anyway, so IMHO the folks running them should just be left to not
get mail from qmail users). See CHANGES under the 19961003 entry.
The problem is that *all* of the listed DNS servers for MSN.COM time out
when given an ANY query for MSN.COM. (Yes, this means they're broken.
Surprised?) None of them return anything but NOTIMP on a "version.bind
txt chaos" entry, so it looks like they're running something other than
BIND. (But not tinydns, which I think returns FORMERR.)
(They work fine with CNAME queries, though; so either qmail breaks with
older BIND setups, or with whatever this is MSN is running. Catch-22.)
One possible solution is to fill your local cache with the MX records by
doing an MX query, which should then be returned as answers to the ANY
query qmail is making. Since they have a 1 hour TTL, do it every 30
minutes. "dig msn.com mx > /dev/null" should suffice.
--
Christopher Davis * <[EMAIL PROTECTED]> * <URL:http://www.ckdhr.com/ckd/>
Put location information in your DNS! <URL:http://www.ckdhr.com/dns-loc/>
