Hello,
I'm running a Squid cache (Version 3.1.10) on CentOS 6.6 as a forward proxy which is reachable over a global IPv6 address. For whatever reason, Squid tries to perform PTR lookups on the client's IPv6 address.
The weird thing is, that Squid seems to struggle with the "endianess" of the IPv6 address blocks. For example:
My current client IP is 2003:6e:d79:2104:7163:7ecd:9333:f0be. Squid tries to resolve b.e.f.0.3.3.9.3.c.d.7.e.6.3.7.1.0.4.2.1.7.9.0.d.6.e.0.0.0.3.2.0.ip6.arpa. That means:
b.e.f.0.3.3.9.3.c.d.7.e.6.3.7.1.0.4.2.1.7.9.0.d.6.e.0.0.0.3.2.0.ip6.arpa -> 0.2.3.0.0.0.e.6.d.0.9.7.1.2.4.0.1.7.3.6.e.7.d.c.3.9.3.3.0.f.e.b -> 0230 : 00e6 : d097 : 1240 : 1736 : e7dc : 3933 : 0feb
For comparison:
Squid: 0230:00e6:d097:1240:1736:e7dc:3933:0feb Real: 2003:006e:0d79:2104:7163:7ecd:9333:f0be
It seems, that Squid just messes with the order of the Bytes on each block.
I couldn't find any related bug report on this (checked Squid and CentOS bug tracker), so I'm not sure if it's a CentOS or Squid related problem.
Is anyone else experiencing this? It seems to be happen on IPv6 client addresses only - with IPv4 it works just fine. And besides of these broken PTR lookups Squid is working as expected.
Greetings from Wuppertal Max
Hey Max,
You are using squid 3.1.x which is not supported anymore by the squid development team. It is possible that there is a bug in this version of squid and that it was not reported until now. Squid should not run a PTR record lookup unless there is an acl which requires\wants\needs it.
Details on squid for CentOS at: http://wiki.squid-cache.org/KnowledgeBase/CentOS
In any case the better place to seek for an answer on the issue you have described is in the squid-users mailing list.
All The Bests, Eliezer Croitoru
On 31/01/2015 20:36, Max Grobecker wrote:
Is anyone else experiencing this? It seems to be happen on IPv6 client addresses only - with IPv4 it works just fine. And besides of these broken PTR lookups Squid is working as expected.
Greetings from Wuppertal Max