On 26/08/2016 4:17 a.m., Steve Hill wrote: > > This one just seems to keep coming up and I'm wondering how other people > are dealing with it: > > When you peek and splice a transparently proxied connection, the SNI > goes through the host validation phase. Squid does a DNS lookup for the > SNI, and if it doesn't resolve to the IP address that the client is > connecting to, Squid drops the connection. > > When accessing one of the increasingly common websites that use DNS load > balancing, since the DNS results change on each lookup, Squid and the > client may not get the same DNS results, so Squid drops perfectly good > connections. > > Most of this problem goes away if you ensure all the clients use the > same DNS server as squid, but not quite. Because the TTL on DNS records > only has a resolution of 1 second, there is a period of up to 1 second > when the DNS records Squid knows about doesn't match the ones that the > client knows about. The client and squid may expire the records up to 1 > second apart. FYI: Services sending TTL of just 1 or even a few seconds are abusing the DNS system. Rotating the order of IPs in the RR record is a standardized feature and works just fine with how Squid does its checks. NP: using "8.8.8.8" in both Squid and client does not count as using the same resolver. Because that service is an entire farm of resolvers that can and do respond differently to any two requests - even if they are made simultaneously. Not a single machine using a single cache of DNS data. > > So what's the solution? (Notably the validation check can't be disabled > without hacking the code). > Well, hacking the code. But not necessarily in the obvious way of disabling checks. Redesign in Squid DNS component is needed. If you want to sponsor and/or test that work mail me privately. Though its unlikely to be available for use in the short term . Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
