Re: squid DNS internals confirmation.

On 6/01/2014 5:16 p.m., Eliezer Croitoru wrote:
> I am testing couple cases with squid which was slow on the WAN but fast
> on the LAN.
> The basic issue was that a simple "ping X" has *found* the host dns
> record while squid did not for a long time(more then 30 secs).
>
> To make sure that I am going from the ground up and not from the higher
> levels towards the lower ones I am verifying the basics.
>
> What would squid Domain Name search would be like?
> I see that in the cache.log it first bind a "DNS" sockets one per IP
> version.
> Then it's adding the nameservers from the local "/etc/resolv.conf" file.
>
> Will the "/etc/hosts" file be loaded before these?

/etc/resolv.conf contains the settings for DNS resolver component.

/etc/hosts contains seed entries for the ipcache/fqdncache components.

They are quite separate and order of configuring does not matter.

>
> I do see that a "squid -kreconf" will reload the nameserver and hosts
> settings.
>
> I am not sure I will be able to provide a patch that will show the hosts
> file read progress yet.
>

It does not seem to matter. See below...

> for example I have tried to access this url
> "http://postfix.state-of-mind.de/patrick.koetter/smtpauth/building_RPMS_from_SRPMS.html"
>
> and got:
> ##start
> Unable to determine IP address from host name
> "postfix.state-of-mind.de"
>
> The DNS server returned:
>
> No DNS records
>
> ##END
>
> it took about 15 secs to get this response.
>

... This other request to wikimedia shows the problem:

> # tcpdump -n not port 22
> 07:59:55.008287 IP 192.168.10.121.40062 > 192.168.10.254.53: 46035+ A?
> www.wikipedia.org. (35)
> 07:59:55.008292 IP 192.168.10.121.40062 > 192.168.10.254.53: 50532+
> AAAA? www.wikipedia.org. (35)
> 07:59:55.024514 IP 192.168.10.254.53 > 192.168.10.121.40062: 50532 3/0/0
> CNAME wikipedia-lb.wikimedia.org., CNAME text-lb.esams.wikimedia.org., A
> 91.198.174.192 (116)
> ##END

- Squid sent *2* DNS requests one for each type of IP.

- 16ms later the first response happens.

- how much longer for the second response?

Current Squid versions send both A and AAAA lookups then wait for *both*
to return before using the results.

The error pages you mention are an indication that both responses *did*
come back (eventually) and neither of them contained usable IP addresses
for Squid to contact.

> Now I am a bit unsure about the situation of the test.

So am I even after reading that.

Of all the traces you provided only the tcpdump trace for port 53 when
lookup up http://www.wikipedia.org/ matches up with anything else you
are talking about.

Did your tcpdump disgnostic of port 53 cover the entire period until
well after Squid returned the error page?

What does the dig tool display for www.wikipedia.com when run from the
Squid machine?
 There is only one IP address in the tcpdump output, but tcpdump gives
no indication if it was the IP of the CNAME, or the IP of the master
nameserver responding to the query.

> 1388988544 06/Jan/2014-08:09:04-IST 240 00:00:00:00:00:00
> 192.168.10.100 TCP_MISS 503 3987 GET
> http://bits.wikimedia.org/images/wikimedia-button.png HIER_NONE/- text/html
> 1388988544 06/Jan/2014-08:09:04-IST 404 00:00:00:00:00:00
> 192.168.10.100 TCP_MISS 200 7760 GET
> http://upload.wikimedia.org/wikipedia/meta/1/16/MediaWiki-logo_sister_1x.png
> HIER_DIRECT/91.198.174.208 image/png
>
> and in the above I use "host domain.example.com" before squid will
> contact the service.
>
> So my basic idea is to put a name service on the squid machine to allow
> a more in-depth or a recursive-able dns software to validate the request
> for squid.

That will only help if the problem is due to response delays or the
Squid ipcache being too small for the traffic needs.

If the problem is valid responses with only CNAME records, nothing but
fixing the source DNS zone will help.

If the problem is lost packets, finding out where they are lost will
lead to the proper solution.

Amos
Received on Mon Jan 06 2014 - 06:17:11 MST