Hi,
On Fri, Aug 31, 2018 at 5:54 PM Darcy, Kevin <kevin.da...@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@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 <mysqlstud...@gmail.com>
>> 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.org/mailman/listinfo/bind-users
