Re: [squid-users] RE: HostHeaderForgery on dual stack ipv4/ipv6 machine and ICAP

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_at_mindspring.com