[squid-users] Possible access via v6 when no interfaces present, fixable with dns_v4_first

[Amos Jeffries]

On 19/05/18 14:14, Luke wrote:
> 
> We're interested to know why this copy of Squid acted differently to all the
> others.  One potential clue we noticed is that this particular LAN has a lot
> of v6 trafflic flying around on it, compared to the rest of our networks.  I
> understand Squid runs it's own DNS resolver.  Could something on the local
> LAN be announcing itself and the resolver in Squid picking up on that,
> switching around the order of DNS resolution so that it tries that v6
> address first?

You have not mentioned overriding Squids normal DNS hijacking protection
with the ignore_unknown_nameservers directive. So probably not.

What you are seeing in that DNS result ordering is RFC 6540 (aka BCP
177) required behaviour. When a server is advertising IPv6 addresses,
they have preference over IPv4 ones.

The dns_v4_first option is provided to allow to you "force" use of the
outdated IPv4 protocol. It is a workaround, not a fix.

In normal operation Squid will test those addresses and immediately be
told by the network they are not routed, so move on to the IPv4 ones.
Updating its internal DNS cache appropriately not to try them again
until DNS TTL expires the record or IPv4 starts failing too.


> 
> Anything else we should be looking for?  Guidance appreciated!
> 

Anything that would cause an IPv6 TCP SYN request to result in a timeout
instead of ICMPv6 "not available" response packet. If IPv6 between Squid
and those edge.icloud.com IPv6 servers was working you would not have
noticed anything. That includes values of working such as "blocked at
the firewall".

Since Squid is actually getting DNS results I assume DNS lag is not the
problem. But if it is taking a long time to get those results it can
still be playing a part of the issue as it reduces the amount of time
that can be spent on IPv6 connection attempts.

Next thing after DNS to check is ICMP(v6). ICMP is not an optional
protocol and admin blocking it in firewalls can cause major problems
when IPv6 relies on it for routing. Specifically for MTU detection.
 <https://tools.ietf.org/html/rfc4890>
 <https://sites.google.com/site/ipv6center/icmpv6-is-non-optional>

With port 443 traffic is it increasingly likely that the protocol is not
compatible with HTTP/1.1. If the TCP SYN works fine, but the HTTP
messaging hangs (ICMP fault usually) or produces some weird protocol
response that Squid does not handle it can result in errors.

Some web servers have IPv6 records but hang or crash when IPv6 is
delivered to them. Cloudflare have pretty good IPv6 service, so that is
highly unlikely but worth a check if all else fails to bring up a clue.

Amos