Frequent timeout

Fri Aug 31 22:49:06 UTC 2018

Hi,

On Fri, Aug 31, 2018 at 5:54 PM Darcy, Kevin <kevin.darcy at fcagroup.com> 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<UP,BROADCAST,RUNNING,MULTICAST>  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<link>
        inet6 ::16da:e9ff:fe97:ab71  prefixlen 64  scopeid 0x0<global>
        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 <bind-users at 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 <mysqlstudent at gmail.com>
>> Sent: Friday, August 31, 2018 4:20 PM
>> To: bind-users at 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 at 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 at 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users