Bug 559151
| Summary: | Squid fails to try IPv4 if IPv6 resolution fails with an error | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tom Hughes <tom> |
| Component: | squid | Assignee: | Jiri Skala <jskala> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 12 | CC: | aglotov, henrik, jonathansteffan, jskala, rvokal |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | squid-3.1.8-1.fc12 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-09-01 05:46:51 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Tom Hughes
2010-01-27 09:45:42 UTC
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.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.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. |