Bug 598699
Summary: | ipv6 dns lookup fail on first NS because it is ipv4 addr, and when ipv4 on second NS is refused, request fail | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Frantisek Hanzlik <franta> |
Component: | squid | Assignee: | Jiri Skala <jskala> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 13 | CC: | aglotov, henrik, jonathansteffan, jskala |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
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:55 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
Frantisek Hanzlik
2010-06-01 20:51:41 UTC
Are you saying that you have a secondary DNS server listed in resolv.conf which returns error on any queries and you think Squid does wrong in telling you this? Basically yes. It is our ISP nameserver, which apparently sometimes has this erroneous behaviour and I can do nothing with this. For now I disable him and I probably have no big requirement for second NS, so he can remain disabled. But this situation may occur (although rarely) in real life - what e.g. occured to me - when I will have multihomed box (main and backup internet line, for example) with second DNS at main line ISP, and then when main internet line fail, it will be same status - I will send dns lookups to secondary DNS, but over backup line, and these will be probably refused, as my ISP may expects queries only from its users. What I want say, when is already queried DNS at (resolv.conf) first place, with AAAA type query, and this query isn't successful (and in my case query isn't from this local NS rejected), then same NS should be queried again for A type address. And on IPv4 network maybe AAAA queries should not be ever attempted. (i not know when is is told clearly, excuse me for bad english) 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 I just test squid-3.1.8-1.fc13.i686, on same network from which I report bug (IPv4-only eth0=LAN/eth1=WAN/lo, localhost's resolv.conf has two nameservers, one of them refuses DNS requests). Behavior is now as : 1) when right nameserver is stated first, then all is OK and resolution is done with him (only): 23:19:10.903106 IP dorticek.dpscernovice.home.34163 > dorticek.dpscernovice.home.domain: 6641+ A? www.google.de. (31) ... 23:19:11.200769 IP dorticek.dpscernovice.home.domain > dorticek.dpscernovice.home.34163: 6641 4/4/0 CNAME www.google.com., CNAME www.l.google.com., A 74.125.87.99, A 74.125.87.104 (183) 2) when at resolv.conf first position is stated nameserver, which refuse request, then things go bad - nameserver at second position isn't questioned and squid respond with error 503 Service Unavailable: DNS dialog: 23:23:45.958423 IP 82.100.48.194.33988 > 160.218.43.200.53: 46136+ A? www.google.da. (31) 23:23:45.972756 IP 160.218.43.200.53 > 82.100.48.194.33988: 46136 Refused- 0/0/0 (31) and result on lynx screen: ----- The requested URL could not be retrieved The following error was encountered while trying to retrieve the URL: http://www.google.da/ Unable to determine IP address from host name "www.google.da" The DNS server returned: Refused: The name server refuses to perform the specified operation. This means that the cache was not able to resolve the hostname presented in the URL. Check if the address is correct. ------ Right behavior should be to send DNS request to remaining nameservers in resolv.conf, not stop when first fail. that is a different bug/feature compared to the original report where it incorrecly advanced to the next server on a successful AAAA not found response. Please file a new report on this other issue. not entirely sure it really is a bug, but agree that it's nicer to the admin if wrongly configured resolvers are ignored. 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. |