Re: [squid-users] squid 3.3.8 failed to start because of hard-coded acl with ::1

On 1/01/2014 10:40 a.m., Craig R. Skinner wrote:
> On 2013-12-31 Tue 23:07 PM |, Eliezer Croitoru wrote:
>> Hey Craig,
>>
>> I want to verify the issue.
>> Do these FreeBSD machines operate only on the ipv4 level?
>
> As I wrote Eliezer, I use OpenBSD which is dual stack.
>
> I included a link to a bug verified by the FreeBSD ports team.
>
>>
>> The line you have mentioned:
>> http://bazaar.launchpad.net/~squid/squid/3-trunk/view/head:/src/cf.data.pre#L847
>> Assumes that the machine is ipv6 enabled by default.
>
> It's very easy to test. No kernel or squid recompile needed.
>
> By setting the DNS resolver to use IPv4 only, squid can't start/parse

Exactly.

 * How does Squid know that IP is an IPv6?

 * What about the HTTP request "GET http://[::1]/ HTTP/1.1" ?

 * What about the HTTP request "GET http://facebook.com/ HTTP/1.1" ?

All of those are involving IPv6. The first of those requests requires
the system resolver library to translate from string to numeric
representation ... exactly the same way the config file is using.

Your machine being set to IPv4-only is in the minority. We have to tune
the default configuration for the majority case.

> (i.e. it is a DNS resolution issue):
>
>>>
>>> $ fgrep family /etc/resolv.conf
>>> family inet4
>>>
>
> Re-enabling IPv6 DNS resolution lets squid run again:
>
>>>
>>> $ fgrep family /etc/resolv.conf
>>> #family inet4
>>>
>
> Maybe squid could first check at run time if IPv6 DNS resolution is
> avaliable before requiring IPv6 default ACLs?
>

Possibly the resolv.conf configuration directive could be done earlier
in the configuration sequence, the ACL made non-fatal when an invalid
value is passed for interpretation as an IP address, and Squid updated
to support that family directive from resolv.conf.

Amos
Received on Wed Jan 01 2014 - 07:55:49 MST