On 10.05.2012 01:57, anita wrote:
Hi All,
Can someone throw some light on how the Squid DNS internal client
works?
Squid passes the API a hostname or IP. It generates a packet according
to DNS specifications, using FQDN search-list construction if necessary,
sends packets to a list of NS and validates the response before sending
a list of IPs or FQDN back to the waiting Squid component.
I came across this:
Disadv of using internal client
Can use only the DNS nameservers mentioned in the squid.conf file for
resolution. If it is not present there, it will give a DNS error.
That is the disadvantage of the external client, not the internal.
It can EITHER use the dns_nameservers list OR the system default
(/etc/resolv.conf) list, not both.
Adv of using external client (uses system libraries: sys calls like
gethostbyname, ..)
Can use DNS nameservers + etc/hosts or WINS ,etc for lookup depending
on
configuration if nameservers report negative.
(courtesy:
http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/web-squid-dns-client-options.html)
But what I dont understand is, I am using only DNS internal client
for my
squid. But I have not configured any nameservers and hence did not
mention
that in my squid.conf. In this case, it is anyway reading from
/etc/hosts
file. So how is it different from the external DNS client except for
the ttl
part?
I especially dont understand the advantage of using the external
client,
i.e. it can look up outside nameservers. I believe in my case, it is
any way
looking up into etc/host file when i use the internal client.
That info was written for Squid-2.3. Current Squid use the /etc/hosts
file, config dns_nameservers list, the system /etc/resolv.conf list, and
on Windows the registry listed DNS servers for the internal client.
The one remaining disadvantage to the internal client is that it does
not use Bonjour or mDNS lookups like most default system resolvers use.
Since the external process uses the system default resolver library it
gets that functionality as basic. However this can be worked around by
pointing at a local resolver process that gateways regular DNS packets
to those services.
Amos
