Re: squid DNS internals confirmation.

On 2014-01-07 12:08, Eliezer Croitoru wrote:
> On 06/01/14 08:16, Amos Jeffries wrote:
>> On 6/01/2014 5:16 p.m., Eliezer Croitoru wrote:
> <SNIP>
>>>
>>> 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.
>
> OK and it is good to know.
>
>>
>>
>>>
>>> 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...
>>
> Indeed from couple aspects such as too much logs etc.
> It is important as a service start-up sequence that needs to be
> understood by a human.
>
>>> 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.
>>
> Indeed.
>
>> - 16ms later the first response happens.
>>
> Indeed.
>
>> - how much longer for the second response?
> There wasn't ... at all time I was capturing using tcpdump.
>

Aha. Then the first place to look is the DNS timeout handler. To make
sure it is completing the transaction as if only that query had a
zero-result response. The A record returned earlier should still be sent
back to the caller.

>> 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?
> Yes but note that it's a test that was repeated more then once and the
> daemon was restarted frequently.
>

Thats okay. We just need to be sure if Squid is producing that "no
results" message when a) the A record *was* known, and b) the AAAA was
still pending.

In such a case Squid should be either using the A record found. Or
returning a different error message (mentioning one of the timeouts
instead of no-dns-results).

>>> 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.
> A basic assumption which we assume is not the answer.

No need to assume. The dig trace tests that and shows it to be not the
case.

>>
>> If the problem is lost packets, finding out where they are lost will
>> lead to the proper solution.
>>
>> Amos
>>
>
> I do assume that the only choice now is between iterative and
> recursive dns server behaver.
> The local dns server behaves like a non-routing friendly system.
> I do not like it but the ISP and all other organizations host a DNS
> system just because this specific issue do exists.
>

A recursive DNS resolver is very much like Squid. They are both there to
optimize and cache the traffic for their respective protocols. To
prevent flooding end server with 100% of all client traffic. And to
allow per-network upgrade to new protocol extensions.

Amos
Received on Mon Jan 06 2014 - 23:26:41 MST