[squid-users] Reverse DNS Lookup for client IPs

[Stefan Hölzle]

On 04.02.2016 14:22, Amos Jeffries wrote:
> On 5/02/2016 12:41 a.m., Stefan Hölzle wrote:
>> Hello,
>>
>> I'm using a squid configured as proxy.
>> According to the cache log, squid is doing a reverse dns lookup for
>> client ips:
>>
>> 78,3| dns_internal.cc(1794) idnsPTRLookup: idnsPTRLookup: buf is 42
>> bytes for SOME_SOURCE_IP
>>
>> I'm only using the following configuration parameters that might be
>> relevant for this issue.
>> external_acl_type
>> acl aclname src
>> acl aclname dst
>> acl aclname dstdom_regex
>> acl aclname port
>> acl aclname proxy_auth
>> acl aclname external
>> acl aclname url_regex
>>
>> Any ideas why squid is doing PTR lookups anyway ?
> Because that list is incomplete.
>
> The format parameters for external_acl_type, any *_extras rules for
> helper formats, and logformat rules also may make use of the client
> hostname (if any).
>
> Also, anyone viewing the cachemanager clientdb report will trigger some
> as the report is generated.
>
> Amos
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
Thanks for the quick reply Amos.

* Used formats for external_acl_type are: %LOGIN, %SRC
* There are no *_extras rules defined (store_id_extras
<http://www.squid-cache.org/Doc/config/store_id_extras/>,
url_rewrite_extras
<http://www.squid-cache.org/Doc/config/url_rewrite_extras/>)
* logformat defaults are used (there should be nothing in there
responsible for a ptr lookup)

I guess its the cachemanager then.
There are actually PTR results listed in the client_list of the
cachemanager.

I tried blocking access to the cachemanager by adding the folling rule:
http_access deny manager

However, squid still does PTR lookups.
How can I prevent the clientdb reports to be generated ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160204/a78f7f9f/attachment.html>