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

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.

Regards
Henrik