Henrik Nordström wrote:
tis 2008-01-08 klockan 13:53 +0100 skrev Bernhard Schmidt:
Hi,
I've been running Squid 3.0-ipv6 branch and now 3.HEAD for quite some
time and found that after an upgrade my Squid cache was wildly crashing
with
assertion failed: ipcache.cc:995: "tmpbuf"
This is related to recursive processing of CNAME DNS responses recently
added to Squid-3 in December.
I wonder.. do we really need to recursively resolve CNAME response? We
sent an A / AAAA query, and all resolveds I know of do the recursion and
include the answer from start.
Has worked forever for Squid-2 without recursing into cname responses.
It has worked for A records because the trend there has been for people
to use A records commonly. These days of AAAA records and long-IP have
seen a major increase in CNAME records pointing at shared AAAA instead
of multiple individual AAAA.
When I was fixing it, I found a large number of those 'cannot connect to
X website' errors last year with A records was because that website used
CNAME redirection and the user was doing internal DNS.
The short of it is that without CNAME resolution either directly or via
the external-DNS helper a very large proportion of usable AAAA records
show up as false-failures.
The assert problem is a case of why the cached list of IPA has a pointer
one line and NULL a few later!
Bernhard:
Can you get a cache.log trace of section 14 please?
On a wacky side-thought: does changing the assert to (tmpbuf != NULL)
fix it for you?
Amos
--
Please use Squid 2.6STABLE17 or 3.0STABLE1.
There are serious security advisories out on all earlier releases.
