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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
