Re: [squid-users] Cannot select peer when request is IP address

On 03/12/2013 02:25, Amos Jeffries wrote:
> On 3/12/2013 11:45 a.m., Brett Lymn wrote:
>> On Mon, Dec 02, 2013 at 11:53:40AM +0000, Stephen Borrill wrote:
>>> On Sun, 1 Dec 2013, Amos Jeffries wrote:
>>>> On 30/11/2013 5:03 a.m., Stephen Borrill wrote:
>>>>> I've found a problem with selecting a parent cache if the request is an
>>>>> IP address. Tested with various versions including 3.3.10. Example
>>>>> config fragment is below:
>>>>>
>>>>> cache_peer 192.168.1.143 parent 3128 0 no-query no-digest default
>>>>> name=prox1
>>>>> cache_peer 192.168.1.144 parent 3128 0 no-query no-digest name=prox2
>>>>> never_direct allow all
>>>>> acl domlist dstdomain -n .bbc.co.uk
>>>>
>>>> "-n" means do not use DNS when evaluating the dstdomain against a
>>>> raw_IP. One guess what requesting http://123.234.123.234/ does?
>>>
>>> -n was added later in an attempt to get it working. The problem still
>>> occurs without -n.
>>>
>>
>> Could it be bug 3848?
>>
>
> Its more likely the text string "123.234.123.234" does not match the
> domain name pattern .*(bbc\.co\.uk)$ nor does it have a PTR reverse-DNS
> record that resolves to any domain name that could match even if the -n
> option was not there to prevent PTR lookup.

I don't see why this breaks the parent selection rules though.

Yes, this looks like bug 3848 (thanks Brett!), except that following on
Amos' mail, I've checked and found that it makes no difference whether a
PTR record is present or not.

Going back to the original config (which is a distilled version for
testing based on our production system which is exhibiting the problem).
If I comment out the top two cache_peer_access lines (the ones that
reference domlist), then the request succeeds.

acl domlist dstdomain .bbc.co.uk
cache_peer_access prox1 deny domlist
cache_peer_access prox2 allow domlist
cache_peer_access prox1 allow all
cache_peer_access prox2 deny all

If the domlist acl has exactly the IP address being requested in it,
then the request succeeds.

-- 
Stephen