Re: assertion failed: ipcache.cc:995: "tmpbuf" in 3.HEAD-CVS

From: Amos Jeffries <squid3@dont-contact.us>
Date: Wed, 09 Jan 2008 17:52:27 +1300

Henrik Nordström wrote:
> ons 2008-01-09 klockan 16:28 +1300 skrev Amos Jeffries:
>> In those cases its a broken server as you point out, and will respond
>> with naked CNAME whether asked for A or AAAA.
>
> If your DNS resolver server responds with a naked CNAME in response to a
> A query then the requested node has a CNAME, but the node the CNAME
> points at do not have an A record.
>
> Same for AAAA queries when there is no AAAA records for the requested
> host.
>
> It's the same as a blank response. Node fount, but requested record type
> not found in the node, same as when you ask for an A record on a host
> only having AAAA or the other way around, without CNAME..
>
> It's not an error response as the node as such do exist. And it's not an
> empty response as there is data which may be meaningful to the requestor
> even if it's not of the record type requested.
>
> There may be other such related records in the response, for example
> PTR. You should only look for and count the record you asked for, it's
> safe to ignore all else.
>
>> Ah, I get your point though.
>>
>> It clashes with my experimental results which made me start on the CNAME
>> effort in the first place. But saying that, the failover code has had
>> much improvement since then which may have skewed the results.
>
>> I'm going to wrap all the CNAME code inside a new option
>> --with-dns-cname and add a stat counter to keep track of exactly how
>> many pure-CNAMEs are encountered by squid.
>
> bare CNAMEs is expected. Nothing strange with that. See above.
>
>> For now the option will be disabled by default, but the counter will
>> always run.
>
> Ok.
>
> I assume there is also counters for A / AAAA queries and responses.

Hmm, not yet. But good point, there should be.

Amos

-- 
Please use Squid 2.6STABLE17 or 3.0STABLE1.
There are serious security advisories out on all earlier releases.
Received on Tue Jan 08 2008 - 21:52:12 MST

This archive was generated by hypermail pre-2.1.9 : Wed Jan 30 2008 - 12:00:09 MST