Frequent timeout

2018-08-31 Thread Alex 
Hi,

Would someone please help me understand why I'm receiving so many
timeouts? This is on a fedora28 system with bind-9.11.4 acting as a
mail server and running on a cable modem.

It appears to happen during all times, including when the link is
otherwise idle.

31-Aug-2018 16:52:57.297 query-errors: debug 2: fetch completed at
../../../lib/dns/resolver.c:3927 for support.coxbusiness.com/A in
10.000171: timed out/success
[domain:support.coxbusiness.com,referral:2,restart:4,qrysent:5,timeout:4,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]

31-Aug-2018 17:06:42.655 query-errors: debug 2: fetch completed at
../../../lib/dns/resolver.c:3927 for dell.ns.cloudflare.com/A in
10.000108: timed out/success
[domain:cloudflare.com,referral:0,restart:2,qrysent:13,timeout:12,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]

What more information can I provide to troubleshoot this?

Is it possible that even though the link otherwise seems to be
operating okay that there could still be some problem that would
affect DNS traffic?

I've also clear all firewall rules, and it's not even all queries which fail.

Thanks,
Alex
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Frequent timeout

2018-08-31 Thread John W. Blue via bind-users 
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 with anything troubleshooting related it is a process of elimination.

Good hunting!

John

Sent from Nine

From: Alex 
Sent: Friday, August 31, 2018 4:20 PM
To: bind-users@lists.isc.org
Subject: Frequent timeout

Hi,

Would someone please help me understand why I'm receiving so many
timeouts? This is on a fedora28 system with bind-9.11.4 acting as a
mail server and running on a cable modem.

It appears to happen during all times, including when the link is
otherwise idle.

31-Aug-2018 16:52:57.297 query-errors: debug 2: fetch completed at
../../../lib/dns/resolver.c:3927 for support.coxbusiness.com/A in
10.000171: timed out/success
[domain:support.coxbusiness.com,referral:2,restart:4,qrysent:5,timeout:4,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]

31-Aug-2018 17:06:42.655 query-errors: debug 2: fetch completed at
../../../lib/dns/resolver.c:3927 for dell.ns.cloudflare.com/A in
10.000108: timed out/success
[domain:cloudflare.com,referral:0,restart:2,qrysent:13,timeout:12,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]

What more information can I provide to troubleshoot this?

Is it possible that even though the link otherwise seems to be
operating okay that there could still be some problem that would
affect DNS traffic?

I've also clear all firewall rules, and it's not even all queries which fail.

Thanks,
Alex
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Frequent timeout

2018-08-31 Thread Darcy, Kevin 
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 "canary in the coal mine" for conditions which lead to packet loss,
sometimes even an early warning of developing WAN and/or configuration
issues.


   - Kevin

On Fri, Aug 31, 2018 at 5:36 PM John W. Blue via bind-users <
bind-users@lists.isc.org> wrote:

> 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 with anything troubleshooting related it is a process of
> elimination.
>
> Good hunting!
>
> John
>
> Sent from Nine 
> --
> *From:* Alex 
> *Sent:* Friday, August 31, 2018 4:20 PM
> *To:* bind-users@lists.isc.org
> *Subject:* Frequent timeout
>
> Hi,
>
> Would someone please help me understand why I'm receiving so many
> timeouts? This is on a fedora28 system with bind-9.11.4 acting as a
> mail server and running on a cable modem.
>
> It appears to happen during all times, including when the link is
> otherwise idle.
>
> 31-Aug-2018 16:52:57.297 query-errors: debug 2: fetch completed at
> ../../../lib/dns/resolver.c:3927 for support.coxbusiness.com/A in
> 10.000171: timed out/success
> [domain:support.coxbusiness.com
> ,referral:2,restart:4,qrysent:5,timeout:4,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]
>
> 31-Aug-2018 17:06:42.655 query-errors: debug 2: fetch completed at
> ../../../lib/dns/resolver.c:3927 for dell.ns.cloudflare.com/A in
> 10.000108: timed out/success
> [domain:cloudflare.com
> ,referral:0,restart:2,qrysent:13,timeout:12,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]
>
> What more information can I provide to troubleshoot this?
>
> Is it possible that even though the link otherwise seems to be
> operating okay that there could still be some problem that would
> affect DNS traffic?
>
> I've also clear all firewall rules, and it's not even all queries which
> fail.
>
> Thanks,
> Alex
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Frequent timeout

2018-08-31 Thread Alex 
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, 
> under the same conditions, can fail completely. Thus, DNS is often the 
> "canary in the coal mine" for conditions which lead to packet loss, sometimes 
> even an early warning of developing WAN and/or configuration issues.

Thanks so much for your help. I have some familiarity with tcpdump and
will investigate.

The interface does show some packet loss:

br0: flags=4163  mtu 1500
inet 68.195.193.45  netmask 255.255.255.248  broadcast 68.195.193.47
inet6 fe80::16da:e9ff:fe97:ab71  prefixlen 64  scopeid 0x20
inet6 ::16da:e9ff:fe97:ab71  prefixlen 64  scopeid 0x0
ether 14:da:e9:97:ab:71  txqueuelen 1000  (Ethernet)
RX packets 1610535  bytes 963148307 (918.5 MiB)
RX errors 0  dropped 5066  overruns 0  frame 0
TX packets 1958053  bytes 1243814299 (1.1 GiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

# uptime
 18:45:08 up  2:49,  1 user,  load average: 0.46, 0.53, 0.66

Is some packet loss such as the above to be expected? I recall doing
some network tests some time ago and found much of it was IPv6
traffic, which is not being used.

bind is running on localhost, so I will trace packets there, but what
am I looking for, to suspect it's a network problem? Will the normal
tcpdump packet size defaults suffice, or should I be capturing larger
amounts from each packet?

This is what I'll be doing for Labor Day weekend, so any help would
really be appreciated. Cablevision/Optonline has told me there are no
problems, but their tests aren't very thorough - if ping works and
doesn't drop packets at that particular time, the link must be fine.

Thanks,
Alex





>
>   
>  - Kevin
>
> On Fri, Aug 31, 2018 at 5:36 PM John W. Blue via bind-users 
>  wrote:
>>
>> 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 with anything troubleshooting related it is a process of 
>> elimination.
>>
>> Good hunting!
>>
>> John
>>
>> Sent from Nine
>> 
>> From: Alex 
>> Sent: Friday, August 31, 2018 4:20 PM
>> To: bind-users@lists.isc.org
>> Subject: Frequent timeout
>>
>> Hi,
>>
>> Would someone please help me understand why I'm receiving so many
>> timeouts? This is on a fedora28 system with bind-9.11.4 acting as a
>> mail server and running on a cable modem.
>>
>> It appears to happen during all times, including when the link is
>> otherwise idle.
>>
>> 31-Aug-2018 16:52:57.297 query-errors: debug 2: fetch completed at
>> ../../../lib/dns/resolver.c:3927 for support.coxbusiness.com/A in
>> 10.000171: timed out/success
>> [domain:support.coxbusiness.com,referral:2,restart:4,qrysent:5,timeout:4,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]
>>
>> 31-Aug-2018 17:06:42.655 query-errors: debug 2: fetch completed at
>> ../../../lib/dns/resolver.c:3927 for dell.ns.cloudflare.com/A in
>> 10.000108: timed out/success
>> [domain:cloudflare.com,referral:0,restart:2,qrysent:13,timeout:12,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]
>>
>> What more information can I provide to troubleshoot this?
>>
>> Is it possible that even though the link otherwise seems to be
>> operating okay that there could still be some problem that would
>> affect DNS traffic?
>>
>> I've also clear all firewall rules, and it's not even all queries which fail.
>>
>> Thanks,
>> Alex
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>> unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>> unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.o

Re: Frequent timeout

2018-08-31 Thread Chuck Swiger via bind-users 
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 be expected? I recall doing
> some network tests some time ago and found much of it was IPv6
> traffic, which is not being used.

0.3% dropped packets is a bit unusual for a NIC running against a switch;
it would be quite normal for a hub.  However, Linux tends to also count
various things like unknown VLAN tags, unknown protocols (ie, IPv6 traffic
on an IPv4-only host), etc as dropped RX packets.

Supposedly ethtool -S helps distinguish between actual interface errors
and traffic that your machine chooses to drop.

Regards,
-- 
-Chuck

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users