Bug 598699 - ipv6 dns lookup fail on first NS because it is ipv4 addr, and when ipv4 on second NS is refused, request fail
ipv6 dns lookup fail on first NS because it is ipv4 addr, and when ipv4 on se...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: squid (Show other bugs)
13
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Jiri Skala
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-01 16:51 EDT by Frantisek Hanzlik
Modified: 2014-11-09 17:33 EST (History)
4 users (show)

See Also:
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 01:46:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Frantisek Hanzlik 2010-06-01 16:51:41 EDT
Description of problem:
squid on firewall/internet gateway on IPv4 only LAN and internet too networks, squid binds with eth0 (LAN) and lo interfaces on port 3128, .
"/etc/named.conf" contain entries:

search dpscernovice.home
nameserver 127.0.0.1
nameserver 160.218.10.200

(local caching NS, which is authoritative for LAN domain "dpscernovice.home")
When client sent request (GET http://fajn.hanzlici.cz/ in example below, which resolve to IPv4 address), squid does:
- ask first (local) DNS server, but for IPv6 address. Response is NoError, but empty, and authoritative NS is returned.

- then squid query resolv.conf second NS, but for IPv4 address. When this query is refused, client's request fail with error 503 "Service Unavailable" and squid return page with text:
=====================
The following error was encountered while trying to retrieve the URL: http://fajn.hanzlici.cz/

     Unable to determine IP address from host name "fajn.hanzlici.cz"

   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.
=====================

When second (just failing) nameserver in /etc/resolv.conf is removed, squid behaves slightly better - ask local NS for IPv6 addr. and then ask him again for IPv4 address. Which correctly obtain and then without problems satisfy client request.
There isn't differences when "dns_v4_fallback" is "on" or "off".

Right behavior in this case should be probably:
- not ask for AAAA type on IPv4-only network
- when now do it, then should do second query on same nameserver for IPv4 address type.


1) Communication, as was captured by tcpdump on machine where squid and bind (and in this case client - lynx too) runs:
     127.0.0.1       127.0.0.1  TCP      41356 > 3128 [SYN] Seq=0 Win=32792 Len=0 MSS=16396 TSV=43872050 TSER=0 WS=6
     127.0.0.1       127.0.0.1  TCP      3128 > 41356 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=16396 TSV=43872050 TSER=43872050 WS=6
     127.0.0.1       127.0.0.1  TCP      41356 > 3128 [ACK] Seq=1 Ack=1 Win=32832 Len=0 TSV=43872050 TSER=43872050
     127.0.0.1       127.0.0.1  HTTP     GET http://fajn.hanzlici.cz/ HTTP/1.0 
     127.0.0.1       127.0.0.1  TCP      3128 > 41356 [ACK] Seq=1 Ack=257 Win=33856 Len=0 TSV=43872050 TSER=43872050
     127.0.0.1       127.0.0.1  DNS      Standard query AAAA fajn.hanzlici.cz
     127.0.0.1       127.0.0.1  DNS      Standard query response
 82.100.48.194  160.218.10.200  DNS      Standard query A fajn.hanzlici.cz
160.218.10.200   82.100.48.194  DNS      Standard query response, Refused
     127.0.0.1       127.0.0.1  HTTP     HTTP/1.0 503 Service Unavailable  (text/html)
     127.0.0.1       127.0.0.1  TCP      41356 > 3128 [ACK] Seq=257 Ack=3928 Win=49280 Len=0 TSV=43872128 TSER=43872128
     127.0.0.1       127.0.0.1  TCP      3128 > 41356 [FIN, ACK] Seq=3928 Ack=257 Win=33856 Len=0 TSV=43872129 TSER=43872128
     127.0.0.1       127.0.0.1  TCP      41356 > 3128 [ACK] Seq=257 Ack=3929 Win=49280 Len=0 TSV=43872169 TSER=43872129
     127.0.0.1       127.0.0.1  TCP      41356 > 3128 [FIN, ACK] Seq=257 Ack=3929 Win=49280 Len=0 TSV=43875130 TSER=43872129
     127.0.0.1       127.0.0.1  TCP      3128 > 41356 [ACK] Seq=3929 Ack=258 Win=33856 Len=0 TSV=43875130 TSER=43875130


2) "/etc/squid/squid.conf":
acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32
acl localnet src 192.168.0.0/16	# RFC1918 possible internal network
acl SSL_ports port 443
acl Safe_ports port 80		# http
acl Safe_ports port 21		# ftp
acl Safe_ports port 443		# https
acl Safe_ports port 70		# gopher
acl Safe_ports port 210		# wais
acl Safe_ports port 1025-65535	# unregistered ports
acl Safe_ports port 280		# http-mgmt
acl Safe_ports port 488		# gss-http
acl Safe_ports port 591		# filemaker
acl Safe_ports port 777		# multiling http
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access deny to_localhost
http_access allow localnet
http_access allow localhost
http_access deny all
http_port 192.168.1.254:3128
http_port 127.0.0.1:3128
hierarchy_stoplist cgi-bin ?
cache_dir ufs /var/spool/squid 500 16 256
coredump_dir /var/spool/squid
refresh_pattern ^ftp:		1440	20%	10080
refresh_pattern ^gopher:	1440	0%	1440
refresh_pattern -i (/cgi-bin/|\?) 0	0%	0
refresh_pattern .		0	20%	4320


Version-Release number of selected component (if applicable):
squid-3.1.4-1.fc13.i686 (squid-3.1.3-2.fc13.i686 probably too)
bind-9.7.0-10.P2.fc13.i686
Comment 1 Henrik Nordström 2010-06-01 18:51:12 EDT
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?
Comment 2 Frantisek Hanzlik 2010-06-01 19:22:59 EDT
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.
Comment 3 Frantisek Hanzlik 2010-06-01 19:37:51 EDT
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)
Comment 4 Fedora Update System 2010-08-24 18:10:30 EDT
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
Comment 5 Fedora Update System 2010-08-24 18:10:33 EDT
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
Comment 6 Fedora Update System 2010-08-24 18:10:39 EDT
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
Comment 7 Fedora Update System 2010-08-24 18:12:51 EDT
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
Comment 8 Fedora Update System 2010-08-24 21:24:33 EDT
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
Comment 9 Fedora Update System 2010-09-01 01:46:41 EDT
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.
Comment 10 Fedora Update System 2010-09-02 16:42:55 EDT
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.
Comment 11 Fedora Update System 2010-09-03 05:27:43 EDT
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
Comment 12 Fedora Update System 2010-09-05 13:20:58 EDT
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
Comment 13 Fedora Update System 2010-09-05 13:21:21 EDT
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
Comment 14 Fedora Update System 2010-09-05 13:21:43 EDT
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
Comment 15 Frantisek Hanzlik 2010-09-05 18:09:50 EDT
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.
Comment 16 Henrik Nordström 2010-09-06 03:33:48 EDT
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.
Comment 17 Fedora Update System 2010-09-15 03:10:47 EDT
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.
Comment 18 Fedora Update System 2010-09-15 18:27:56 EDT
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.
Comment 19 Fedora Update System 2010-09-15 18:34:15 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.