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
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
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
-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
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
5 matches
Mail list logo
