Re: Frequent timeout

2018-09-11 Thread Alex
Hi, Here is a much more reasonable network capture during the period where there are numerous SERVFAIL errors from bind over a short period of high utilization. https://drive.google.com/file/d/1UrzvB-pumVjPvlmd6ZSnHi-XVynI8y3y/view?usp=sharing This is when our 20mbs cable upstream link was satura

Re: Frequent timeout

2018-09-11 Thread Carl Byington
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2018-09-11 at 14:19 -0400, Alex wrote: > This is when our 20mbs cable upstream link was saturated and resulted > in DNS query timeout errors. resulting in these SERVFAIL messages. Not specific to dns, but this looks like a bufferbloat proble

RE: Frequent timeout

2018-09-11 Thread John W. Blue
If you use wireshark to slice n dice the pcap .. "dns.flags.rcode == 2" shows all of your SERVFAIL happens on localhost. If you switch to "dns.qry.name == storage.pardot.com" every single query is localhost. Unless you have another NIC that you are sending traffic over this does not look like

Re: Frequent timeout

2018-09-11 Thread Alex
Hi, On Tue, Sep 11, 2018 at 2:47 PM John W. Blue wrote: > > If you use wireshark to slice n dice the pcap .. "dns.flags.rcode == 2" shows > all of your SERVFAIL happens on localhost. > > If you switch to "dns.qry.name == storage.pardot.com" every single query is > localhost. > > Unless you have

RE: Frequent timeout

2018-09-11 Thread John W. Blue
I will walk back my previous comments and just say that bandwidth may be in play because anytime you soak a circuit it is not good. Take a look at this query sequence: dns.qry.type == 28 && dns.qry.name == concured.co Packet 42356 shows a query for concurred.co. Packets 42357/8 show 68.195