Re: squid internal DNS weirdness?

It is true that Squid does not understand the notion of using the IP
0.0.0.0 being the local server, and thinks that the replies are spoofed
since they are being received from another IP.

This is also true when using secured resolver libraries that verifies
the IP from where the reply is received.

I am somewhat reluctant at doing anything about this in Squid. In my
opinion it is better to just specify 127.0.0.1 in /etc/resolv.conf
instead of 0.0.0.0, to directly address the loopback interface which is
just as standard.

Sidenote: The 0.0.0.0 notion is not an "official" standard for
addressing the local machine, but works on most OS:es regardless..

--
Henrik Nordstrom
Squid hacker
Adrian Chadd wrote:
> 
> Hi squid-dev guys,
> 
> What do you think of this?
> 
> Adrian
> 
> ----- Forwarded message from "Kurt J. Lidl" <lidl@pix.net> -----
> 
> Date: Tue, 13 Feb 2001 10:03:01 -0500
> From: "Kurt J. Lidl" <lidl@pix.net>
> To: Adrian Chadd <adrian@freebsd.org>
> Cc: "Kurt J. Lidl" <lidl@pix.net>
> Subject: Re: more article FYIs..
> X-Mailer: Mutt 0.93.2
> 
> On Tue, Feb 13, 2001 at 12:58:30PM +0100, Adrian Chadd wrote:
> > uhm, squid's internal DNS isn't synchronous - it will handle multiple
> > parallel requests that are outstanding and cache their responses. If
> > the internal DNS routines were synchronous, they wouldn't be a default. :)
> 
> Then it is broken.  (See below)
> 
> > In fact, we don't use the system resolver at all - the internal DNS
> > code in squid actually implements creating, sending, recieving, parsing
> > and validating DNS packets. This cuts down on context switch and IPC
> > overhead.
> >
> > Squid-2.3 will query the servers in /etc/resolv.conf . Squid-2.4 will
> > also parse your /etc/hosts file and permanently cache any entries found
> > there. If you are seeing a slowdown with internal DNS configured, you
> > may wish to check that the first resolvers in /etc/resolv.conf are
> > reachable and return quickly.
> 
> It doesn't work properly if the machine has the following in its
> /etc/resolv.conf:
> 
> domain pix.net
> nameserver 0.0.0.0
> nameserver 192.111.45.13
> nameserver 198.6.1.5
> 
> The first entry, is, as I'm sure you know a completely legitimate way
> of specifying localhost as the resolving host.
> 
> Squid then ignores all the answers coming back from that nameserver,
> as they are sourced from one of the IP addresses that BIND has bound
> to.  If squid sees 0.0.0.0 as the nameserver, it should walk the interface
> list and figure out what ip addresses are local and accept answers
> from them too.
> 
> Without that logic, squid will always send to the first IP address 0.0.0.0,
> which responds, squid will ignore the response, and then send to the
> second IP address, which after some amount of time, will respond.
> 
> > I hope this helps. :)
> 
> Me too.
> 
> The machine I'm running this on has something like six interfaces that
> it can respond from:
> 
> lidl@gatekeeper-36: netstat -an | grep "\.53"
> tcp         0      0  127.0.0.1.53           *.*                    LISTEN
> tcp         0      0  192.111.45.65.53       *.*                    LISTEN
> tcp         0      0  192.111.45.1.53        *.*                    LISTEN
> tcp         0      0  63.113.184.82.53       *.*                    LISTEN
> tcp         0      0  192.111.45.193.53      *.*                    LISTEN
> tcp         0      0  192.111.45.129.53      *.*                    LISTEN
> udp         0      0  *.53                   *.*
> udp         0      0  127.0.0.1.53           *.*
> udp         0      0  192.111.45.65.53       *.*
> udp         0      0  192.111.45.1.53        *.*
> udp         0      0  63.113.184.82.53       *.*
> udp         0      0  192.111.45.193.53      *.*
> udp         0      0  192.111.45.129.53      *.*
> 
> By switching to the dnsserver program, squid effectively starts believing
> the responses from the (very fast) nameserver listening on 0.0.0.0 -- as
> the dnsserver program doens't toss out those answers.
> 
> If you fix squid, I'll be happy to write an update to my article :-)
> 
> (I still think the dnsserver instruementation hack was a good idea, however.)
> 
> -Kurt
> 
> ----- End forwarded message -----
> 
> --
> Adrian Chadd                    "Programming is like sex:
> <adrian@freebsd.org>               One mistake and you have to support for
>                                     a lifetime." -- rec.humor.funny