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
