ons.
Good hunting!
John
-Original Message-
From: Alex [mailto:mysqlstud...@gmail.com]
Sent: Tuesday, September 11, 2018 1:57 PM
To: John W. Blue; bind-users@lists.isc.org
Subject: Re: Frequent timeout
Hi,
On Tue, Sep 11, 2018 at 2:47 PM John W. Blue wrote:
>
> If you use wireshark
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
does not
look like a bandwidth issue at this particular point in time.
John
-Original Message-
From: Alex [mailto:mysqlstud...@gmail.com]
Sent: Tuesday, September 11, 2018 1:19 PM
To: bind-users@lists.isc.org; John W. Blue
Subject: Re: Frequent timeout
Hi,
Here is a much more reason
-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
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
Hi,
> >> tcpdump -s0 -n -i eth0 port domain -w /tmp/domaincapture.pcap
> >>
> >> You don't need all of the extra stuff because -s0 captures the full packet.
>
> On 06.09.18 18:42, Alex wrote:
> >This is the command I ran to produce the pcap file I sent:
> >
> ># tcpdump -s0 -vv -i eth0 -nn -w
On Thu, Sep 6, 2018 at 5:56 PM John W. Blue wrote:
So that file is full of nothing but queries and no responses which, sadly, is
useless.
Run:
tcpdump -s0 -n -i eth0 port domain -w /tmp/domaincapture.pcap
You don't need all of the extra stuff because -s0 captures the full packet.
On
errupt 16 memory 0xdf20-df22
Thanks,
Alex
>
> John
>
> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Alex
> Sent: Thursday, September 06, 2018 2:54 PM
> To: bind-users@lists.isc.org
> Subject: Re: Frequent t
-users-boun...@lists.isc.org] On Behalf Of Alex
Sent: Thursday, September 06, 2018 2:54 PM
To: bind-users@lists.isc.org
Subject: Re: Frequent timeout
On Thu, Sep 6, 2018 at 3:05 PM John W. Blue wrote:
>
> Alex,
>
> Have you uploaded this pcap with the SERVFAIL's? I didn't have
eptember 06, 2018 1:49 PM
> To: c...@byington.org; bind-users@lists.isc.org
> Subject: Re: Frequent timeout
>
> Hi,
>
> On Mon, Sep 3, 2018 at 12:45 PM Carl Byington wrote:
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > On Sun, 2018
...@byington.org; bind-users@lists.isc.org
Subject: Re: Frequent timeout
Hi,
On Mon, Sep 3, 2018 at 12:45 PM Carl Byington wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Sun, 2018-09-02 at 21:54 -0400, Alex wrote:
> > Do you have any other ideas on how I can
Hi,
On Mon, Sep 3, 2018 at 12:45 PM Carl Byington wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Sun, 2018-09-02 at 21:54 -0400, Alex wrote:
> > Do you have any other ideas on how I can isolate this problem?
>
> Run tcpdump on the external ethernet connection.
>
> tcpdump
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Sun, 2018-09-02 at 21:54 -0400, Alex wrote:
> Do you have any other ideas on how I can isolate this problem?
Run tcpdump on the external ethernet connection.
tcpdump -s0 -vv -i %s -nn -w /tmp/outputfile udp dst port domain
-BEGIN PGP
Hi,
> > When trying to resolve any of these manually, it just returns
> > NXDOMAIN.
>
> What does
>dig -4 71.161.85.209.hostkarma.junkemailfilter.com +trace +nodnssec
> show, and it is consistently NXDOMAIN? That ends here with:
>
> 71.161.85.209.hostkarma.junkemailfilter.com. 2100 IN A
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Sat, 2018-09-01 at 23:45 -0400, Alex wrote:
> (71.161.85.209.hostkarma.junkemailfilter.com): query failed (SERVFAIL)
> (71.161.85.209.bl.score.senderscore.com): query failed (SERVFAIL)
> When trying to resolve any of these manually, it just
Hi,
It was reported there was a permissions problem with my Google Drive
link to the pcap file only allowing access to Google users. This
should now be public:
https://drive.google.com/file/d/1Ui893Lg61psZCR8I_9SJtNqs-Sil_br5/view?usp=sharing
Thanks,
Alex
On Sat, Sep 1, 2018 at 11:45 PM Alex
On Sat, Sep 1, 2018 at 11:25 PM Carl Byington wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Fri, 2018-08-31 at 17:18 -0400, Alex wrote:
> > ../../../lib/dns/resolver.c:3927 for support.coxbusiness.com/A in
>
> After 4 seconds, I get SERVFAIL on that name.
Thank you for your
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Fri, 2018-08-31 at 17:18 -0400, Alex wrote:
> ../../../lib/dns/resolver.c:3927 for support.coxbusiness.com/A in
After 4 seconds, I get SERVFAIL on that name.
> ../../../lib/dns/resolver.c:3927 for dell.ns.cloudflare.com/A in
That name
Hi, Alex--
On Aug 31, 2018, at 3:49 PM, Alex wrote:
> The interface does show some packet loss:
>
> br0: flags=4163 mtu 1500
> [ ... ]
>RX packets 1610535 bytes 963148307 (918.5 MiB)
>RX errors 0 dropped 5066 overruns 0 frame 0
>
> Is some packet loss such as the above to
Hi,
On Fri, Aug 31, 2018 at 5:54 PM Darcy, Kevin wrote:
>
> I'll second the use of tcpdump, and also add that DNS query traffic, using
> UDP by default, tends to be hypersensitive to packet loss. TCP will retry and
> folks may not even notice a slight drop in performance, but DNS queries,
>
I'll second the use of tcpdump, and also add that DNS query traffic, using
UDP by default, tends to be hypersensitive to packet loss. TCP will retry
and folks may not even notice a slight drop in performance, but DNS
queries, under the same conditions, can fail completely. Thus, DNS is often
the
tcpdump is your newest best friend to troubleshoot network issues. You need to
see what (if anything) is being placed on the wire and the responses (if any).
My goto syntax is:
tcpdump -n -i eth0 port domain
I like -n because it prevents a PTR lookup from happing. Why add extra noise?
As
22 matches
Mail list logo
