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.

Reply via email to