Re: squid internal DNS weirdness?

From: Andres Kroonmaa <andre@dont-contact.us>
Date: Tue, 13 Feb 2001 20:41:25 +0200

 I'd think Kurt is doing a wrong thing. He should use single IP via
 his resolv.conf - 127.0.0.1 and be happy. using 0.0.0.0 there gives
 absolutely nothing, could only make bind slower, and clients more
 prone to delays in case some interface goes down.

 Also, what he says about legitimate target of 0.0.0.0 is fine when
 you only talk about local services hidden by local apps. In no sense
 IP 0.0.0.0 is NOT a legitimate DNS server address. and resolv.conf
 is a file to specify an internet nameserver.

 It is also NOT a legitimate address on very many systems. Its a hack,
 made by some for convenience. Of few OS'es I have access to right
 now, WinNT will reject it, solaris 2.5.1 will pass it on to broadcast
 address(!), getting response multiplication, and solaris7 behaves like
 "wanted".

 Aside that implementing "being nice" feature might not be trivial,
 we'd have to keep track of multiple interface states instead of
 one guaranteed 127.0.0.1 (is it required by any RFCs?). Pointless.
 We could do s/0.0.0.0/127.0.0.1/ perhaps?

 what article he is mentioning?

On 13 Feb 2001, at 17:33, Adrian Chadd <adrian@freebsd.org> 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
>

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 Delfi Online
 Tel: 6501 731, Fax: 6501 708
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Tue Feb 13 2001 - 11:45:21 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:30 MST