Re: Problems with internal dns

Ben Fowler wrote:

> It is not clear to me why squid is so bothered about looking up the IP address
> for a requested URL. To my mind if the URL exists in the cache it could be
> delivered to a User Agent (if necessary with a freshness reservation).

Squid looks up the destination host name if

a) It needs to contact the origin server

b) You use any access control directives which requires the IP address.
For example the dst ACL type.

> The internal dns system appears to have two serious problems.
>
> 1) It cannot look up unqualified names, exempli gratia 'squid-12',
> which is a perfectly good hostname for one of my machines whose
> FQHN is squid-12.local.domain.com . Since this machine
> is used as a cache_peer, I can get round this problem by pretending that
> cache_peers must be FQHNs; but the problem remains & I cannot look up
> machines such as 'www-l' which is a local copy of my on-line server.

See append_domain in squid.conf..

> 2) It seems to be unable to choose which NS to use: My resolv.conf is
> as follows,
[...]
> squid appears to put the name servers on a list and always(?) chooses the
> last entry. Can you see why this is unfortunate?

If it does always use the last specified then it is a bug. It is
supposed to be using the first one until it times out, then send the
request to the second one, and so on.

> Given the fact that it may be silly to modify one's resolv.conf to
> accommodate squid, it might be a good idea for squid to use all name
> servers in turn and keep a record of which responds fastest. bind does this
> when it goes out to the root servers, for instance.

Squid is only a light resolver client like all other using
/etc/resolv.conf, and does not do the RTT heuristics like bind or any
full blown DNS resolver. The first nameserver in /etc/resolv.conf is the
one primarily used, the other ones are backup servers in case the first
does not answer.

--
Henrik Nordstrom
Squid hacker