> On Mar 13, 2023, at 4:14 PM, local10 <loca...@tutanota.com> wrote: > > Mar 13, 2023, 21:42 by recovery...@enotuniq.net: > >> Well, it was worth to check it. >> >> >> Next idea is somewhat more complicated. >> >> Install tcpdump. >> Run: >> tcpdump -pni any -s0 -w /tmp/dns.pcap -c 30 udp port 53 or tcp port 53 >> Bounce BIND, wait for a minute at least. >> Do some DNS queries. One or two will do. >> Interrupt tcpdump unless it completes by itself. >> Post dns.pcap. >> > > > Strangely, the issue resolved itself without me having to do anything. Am > really puzzled as to what it was. Perhaps the internet provider suddenly > started to block DNS queries but then allowed them again?
Hard to tell without further data, but it's possible. > If so, why did dig's message say that there was "communications error to > 127.0.0.1#53: timed out"? It really gives an impression that dig was failing > to connect 127.0.0.1 port 53, on which bind was running. > > # dig www.yahoo.com <http://www.yahoo.com> > ;; communications error to 127.0.0.1#53: timed out > ;; communications error to 127.0.0.1#53: timed out > ... > > Maybe someone will shed some light on this. This one is a little misleading. The fact is that BIND tries really hard to resolve your name, trying all sorts of alternate servers and fallbacks to account for timeouts, DNSSEC validation failures, and more. Sometimes that can take a really long time. In one of the outputs you provided previously, you showed "timed out" followed by SERVFAIL. Those are symptoms of this behavior: first query times out with resolver trying things and second query returned the cached (SERVFAIL) failure. Casey
