Description of problem: If an AAAA query for IPv6 addresses fails to return any records then squid happily falls back to an A query to get IPv4 addresses and uses those. If the AAAA query fails with an error (typically SERVFAIL) then it doesn't fall back and just returns an error page saying the site doesn't exist. Version-Release number of selected component (if applicable): squid-3.1.0.15-2.fc12.i686 How reproducible: Every time when visiting a site with this DNS problem. Steps to Reproduce: 1. Point your browser at a squid with IPv6 connectivity 2. Try and visit http://www.ryanair.com/ or http://www.trustnet.com/ Actual results: A squid error page. Expected results: The requested web site.
Seems to work for me with 3.1.3. But as far as I can tell there has not been any releveant DNS fixes since 3.1.0.15 so I am not sure why.
I've just rebuilt the 3.1.3 package from rawhide on F12 and it still doesn't seem to work for me. The machine I'm testing on does have IPv6 which may make a difference to how the resolver handles things?
What error message do you get from Squid? Can you try the 3.1.3-2 build? https://admin.fedoraproject.org/updates/squid
The 3.1.3-2 build is the same. The error is: Unable to determine IP address from host name "www.trustnet.com" Server Failure: The name server was unable to process this query. It is certainly true that an AAAA query for that name returns SERVFAIL which is a pretty bogus response as NXDOMAIN is the correct answer if it doesn't have an IPv6 address. An A query does return a valid address however.
And for me it just works... 1273853880.557 575 127.0.0.1 TCP_MISS/200 117525 GET http://www.trustnet.com/ - DIRECT/194.75.147.242 text/html 1273853898.529 270 127.0.0.1 TCP_MISS/200 10946 GET http://ipv6.google.com/ - DIRECT/2a00:1450:8005::63 text/html dig www.trustnet.com AAAA ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55777 dig www.trustnet.com A ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27650 www.trustnet.com. 10 IN A 194.75.147.242 Question is, why do our result differ?
An idea. Could you try collecing a packet trace of what is goingon on your server? Restart Squid. Record the network traffic using tcpdump tcpdump -n -p -i -s0 -w squid_traffic.pcap port 80 or port 80 or port 3128 replace 3128 by your proxy port if different. make one faling request and stop tcpdump by Ctrl-C (hold Ctrl and press C) If you do not want to attache the trace in public then feel free to drop it in ftp://ftp.squid-cache.se/incoming/
Oops.. one of the port 80 should be 53.
Right. After having a look at some packet traces I've worked out the real problem and why only I am seeing it. I have two nameservers configured, both on my network. The first had DNSSEC disabled and was working fine. The second still had DNSSEC enabled and was rejecting attempts to resolve the A record due to some weird DNSSEC issue. Now normally that's fine as squid resolves everything using the first server and so long as it doesn't fall back to the second one there is no problem. It seems however that when AAAA resolution fails it only tries the A record on the second server and hence that was failing as well, just for different reasons. In total it was doing four resolutions - first AAAA on the primary (SERVFAIL due to upstream returning no records) then AAAA on the secondary (same again) then AAAA on the primary again (same result) and finally one go at A on the secondary. Doing AAAA on each and then A on each would probably be better... I'm back in business anyway, having turned off DNSSEC on the other server now.
What error did the secondary respond with?
All four lookups gave a SERVFAIL response from the local named back to squid.
Right. I see now what is going on. Thanks!
squid-3.1.7-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/squid-3.1.7-1.fc13
squid-3.1.7-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/squid-3.1.7-1.fc12
squid-3.1.7-1.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/squid-3.1.7-1.fc14
squid-3.1.7-1.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update squid'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/squid-3.1.7-1.fc14
squid-3.1.7-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
squid-3.1.7-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
squid-3.1.7-1.fc12.1 has been submitted as an update for Fedora 12. https://admin.fedoraproject.org/updates/squid-3.1.7-1.fc12.1
squid-3.1.8-1.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/squid-3.1.8-1.fc13
squid-3.1.8-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/squid-3.1.8-1.fc14
squid-3.1.8-1.fc12 has been submitted as an update for Fedora 12. https://admin.fedoraproject.org/updates/squid-3.1.8-1.fc12
squid-3.1.8-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
squid-3.1.8-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
squid-3.1.8-1.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.