Frequent timeout

[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 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 <http://www.9folders.com/>
> ------------------------------
> *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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20180831/754d7e13/attachment.html>