Thank you for your response. - my browser and squid proxy live on the same machine (thus hitting the same DNS cache) - my ICAP implementation is not modifying requests yet (that is the goal just taking baby steps getting there) I see the issue quite regularly. Is there any way I can verify that this is indeed the "DNS race condition". I will try turning off IPv6 and ICAP to see if that has any effect. On Mon, Jan 30, 2012 at 12:13:34PM +1300, Amos Jeffries wrote: > On 30/01/2012 6:29 a.m., James R. Leu wrote: > >Hello, > > > >I'm in the process of implementing an ICAP server, but I'm encountering the > >HostHeaderForgery issue quite often when accessing sites that I can reach > >over IPv6. I've read the KB entry about this. It lists > >that co-locating the NAT device and squid on the same machine, > >or enabling EDNS may resolve the issue. > > > >I'm wondering if my issue is specific to dual stack v4/v6 > >or to ICAP. Any suggestions for what I can try to > >work around this issue? If this is specific to > >dual stack v4/v6, I'm here to beat my v6 migration > >drum and I'm willing to help out to resolve it. > > The only relation with IP version is if you have disbaled DNS > lookups of IPv4 in Squid. That could make Squid fail to identify the > IPv4 destination as valid. The latest 3.2 daily snapshot has DNS > updates that work faster and obsolete that option, so should not hit > this particular aspect. > > The only relation ICAP/eCAP/url-rewrite/request_header_access > adaptation have is if they alter the URL and/or Host header to > something that does not sync up. Upstream interception proxies might > fail the verify and produce the conflict error after such > alterations. > > The most common occurance now happening is with websites which force > DNS update changes across the Internet on very short TTL (er "load > balance" via DNS results). Each time the DNS changes IP Squid will > have race between itself and client as to which picks the change up > first. DNS stability takes up to TTL duration to happen. At which > point these load balancers have de-stabilized the network again for > a new IP. We have a patch in testing now, hopefully it will be in > mainstream soon. > > > > > >My test environment: > > > > Linux laptop with dual stack ipv4/ipv6 > > - Fedora rawhide squid (squid-3.2.0.14-6.fc17.x86_64) > > - resolve.conf has v4/v6 nameservers listed > > - squid in intercept mode on same machine as web browser and icap server > > - iptables redirect > > iptables -A OUTPUT -p tcp -m owner --uid-owner 23 -m tcp --dport 80 -j ACCEPT > > iptables -A OUTPUT -p tcp -m tcp --dport 80 -j DNAT --to-destination localhost:3128 > > 3128 is a well known port. You should have a separate (secret) port > for NAT so you can still use 3128 for regular proxy traffic. Best > pratice is to use NAT as a last-resort backup behind other things > like WPAD. > > You are also missing some mangle table rules here which prevent > direct browser->squid contact over the NAT intercept port. It *must* > all go via the NAT intercept mechanisms to such ports for > reliability and avoiding Host verification errors. > > Amos -- James R. Leu jleu@xxxxxxxxxxxxxx
Attachment:
pgp_ry6jllYVT.pgp
Description: PGP signature
