[squid-users] Bizarrely slow, timing out DNS only via Squid :D

Fri Mar 4 02:04:24 UTC 2016

Eliezer,

I haven’t had time to put together a current squid.conf and make it readable, remove sensitive stuff. But we don’t have any DNS-related directives set, it’s all just defaults for that stuff.

As for the other things you asked about:

1. The current resolv.conf looks like this:
```
search tceo

nameserver 192.231.203.3
nameserver 172.16.100.5
```

2. Using `dns_v4_first on` and `dns_nameservers 192.231.203.3 172.16.100.5`, doesn’t make any difference.

3. Here’s a test to your site with a single IPv4 address:

# time squidclient -h 10.100.128.1 http://ngtech.co.il

HTTP/1.1 200 OK
Server: nginx/1.8.0
Date: Fri, 04 Mar 2016 01:51:34 GMT
Content-Type: text/html
Content-Length: 10167
Last-Modified: Tue, 09 Feb 2016 15:56:55 GMT
Accept-Ranges: bytes
Vary: Accept-Encoding
X-Cache: MISS from livestream.tceo
X-Cache-Lookup: MISS from livestream.tceo:3128
Via: 1.1 livestream.tceo (squid/3.5.13)
Connection: close

<content remove for brevity>

real	0m16.339s
user	0m0.000s
sys	0m0.002s

4. Reverse DNS lookups for both DNS servers

# dig -x 192.231.203.3

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.6 <<>> -x 192.231.203.3
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31360
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 8

;; QUESTION SECTION:
;3.203.231.192.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
3.203.231.192.in-addr.arpa. 149	IN	PTR	resolv2.internode.on.net.

;; AUTHORITY SECTION:
203.231.192.in-addr.arpa. 149	IN	NS	ns4.on.net.
203.231.192.in-addr.arpa. 149	IN	NS	ns3.on.net.
203.231.192.in-addr.arpa. 149	IN	NS	ns1.on.net.
203.231.192.in-addr.arpa. 149	IN	NS	ns2.on.net.

;; ADDITIONAL SECTION:
ns1.on.net.		13301	IN	A	203.16.213.172
ns1.on.net.		4681	IN	AAAA	2001:44b8:f020:ff00::80
ns2.on.net.		13906	IN	A	192.231.203.2
ns2.on.net.		12151	IN	AAAA	2001:44b8:8020:ff00::80
ns3.on.net.		13407	IN	A	150.101.197.131
ns3.on.net.		4681	IN	AAAA	2001:44b8:b070:ff00::80
ns4.on.net.		13374	IN	A	192.231.203.4
ns4.on.net.		9533	IN	AAAA	2001:44b8:8060:ff00::80

;; Query time: 23 msec
;; SERVER: 192.231.203.3#53(192.231.203.3)
;; WHEN: Fri Mar  4 12:59:02 2016
;; MSG SIZE  rcvd: 330

# dig -x 172.16.100.5

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.6 <<>> -x 172.16.100.5
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35335
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;5.100.16.172.in-addr.arpa.	IN	PTR

;; AUTHORITY SECTION:
16.172.in-addr.arpa.	86400	IN	SOA	localhost. root.localhost. 1 604800 86400 2419200 86400

;; Query time: 21 msec
;; SERVER: 192.231.203.3#53(192.231.203.3)
;; WHEN: Fri Mar  4 12:59:14 2016
;; MSG SIZE  rcvd: 93

---

Was there there anything else I missed?

> On 4 Mar 2016, at 9:49 AM, Eliezer Croitoru <eliezer at ngtech.co.il> wrote:
> 
> This is where you need to share your squid.conf..
> Also what was the result of the query I mentioned?
> 
> Another one to try is:
> http://www.squid-cache.org/Doc/config/dns_v4_first/
> 
> try adding to the end of squid.conf
> dns_v4_first on
> 
> All The Bests,
> Eliezer
> 
> On 04/03/2016 00:42, Dan Charlesworth wrote:
>> Thanks for your input Eliezer.
>> 
>> I've tested against various public DNS servers at this point so I'm
>> ruling out any DNS-server-side problems. The only time there's any
>> timeouts or slowness is when the request is going through squid. Doesn't
>> seem to matter which HTTP server I'm requesting, whether it returns
>> multiple IPs or not.
>> 
>> Also worth noting that this company has about 30 other sites with mostly
>> identical network topologies and equipment where it's completely fine.
>> 
> 
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160304/ca4b75b7/attachment-0001.html>