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

Henrik Nordström wrote:
> ons 2008-01-09 klockan 11:41 +1300 skrev Amos Jeffries:
>
>> 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.
>
> You missed the point I think.
>
> The query Squid sends to the resolver is a recursive A or AAAA query,
> not a CNAME query. All resolvers I have seen then returns CNAME + the
> recursively resolved A or AAAA entry, and I think this is required.
> Checking, yes, RFC1034 says explicily that the DNS server should do this
> (RFC1034 3.6.2 Aliases and canonical names).
>
> This is why Squid ignored CNAME in the DNS responses and just looks for
> A (and now AAAA). The canonical name of the requested host hasn't been
> interesting to ipcache, just the address record.
>
>> 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.
>
> CNAME to A record works just fine for me. And so do my tests using dig
> to query for sites having a CNAME to AAAA. There is a single query sent
> to the resolver, and in both cases the CNAME + A/AAAA record
> respectively comes back in the answer.
>
> If there is no A/AAAA record of the requested type then just the CNAME
> is returned, as expected.
>
>> 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.
>
> I rather suspect the code fails to properly switch between A/AAAA query
> when seeing just a CNAME in response to the first query... It should not
> be needed to manually recurse.

In those cases its a broken server as you point out, and will respond
with naked CNAME whether asked for A or AAAA.

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.
For now the option will be disabled by default, but the counter will
always run.

Amos

-- 
Please use Squid 2.6STABLE17 or 3.0STABLE1.
There are serious security advisories out on all earlier releases.