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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos/attachments/20150131/7ae2778c/attachment-0004.sig>