On 28/05/2016 4:49 a.m., Antony Stone wrote: > On Friday 27 May 2016 at 17:51:36, Aashima Madaan wrote: > >>> So, does the problem exist if you: >>> >>> 1. Stop Squid >>> 2. Type "host short.domain.name" to resolve the ICAP server manually >>> 3. Start Squid >>> >>> (The last two commands in as quick succession as possible - preferably on >>> a single line separated by a semi-colon) >> >> yes the problem still exists > > That tells me that the problem is not DNS, then. > > Command 2 verifies that DNS resolution is working. > > Command 3 results in the problem. > > Therefore whatever is causing the problem is not DNS. What is causing the problem is that ICAP services need to be working *immediately* and do not wait for DNS results to come back. If they are not available immediately then the service is not contactable for that transaction. Adding /etc/hosts entries makes Squid load the name+IP details on startup before ICAP is used. So the problem does not appear. Also, once Squid has looked it up and got the IP back operations with the ICAP service will start to succeed. > >> on additional debugging by switching on tcpflow, I see squid sends >> OPTIONS request to icap server and that is when it is able to resolve >> DNS and which brings the service up in 3 minutes. > > Have you tried running some sort of packet tracer (eg: wireshark) to check > when Squid is sending the DNS request, where it is sending it to, and whether > it gets a response? > >> Address.cc(389) lookupHostIP: Given Non-IP 'short.domain.name': Name >> or service not known > > Can anyone else shed some light on what this particular message means? > That is Squid checking to see if the ICAP hostname is a raw-IP. It is not, so that correctly wont succeed. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users