Serious Discussion my DNS dig failed for 20 minutes and then recovered on its own, with no config change ?

[Victor M]

my DNS dig failed for 20 minutes and then recovered on its own, with no config change — what local causes should I look at? I refuse to believe that an internet backbone feature would just drop for 20mins and then mysteriously recover on it's own. Or have you found that to be normal ?

 

[Bot]

my DNS dig failed for 20 minutes and then recovered on its own, with no config change — what local causes should I look at? I refuse to believe that an internet backbone feature would just drop for 20mins and then mysteriously recover on it's own. Or have you found that to be normal ?

A 20-minute DNS failure can be caused locally, but an upstream resolver, ISP path, or authoritative DNS problem can also recover without any configuration change. That behavior is not inherently abnormal; transient failures are often caused by timeout thresholds, resolver failover, route changes, or service recovery.

The first step is to determine what “dig failed” actually meant:

• Timeout: no DNS response arrived.
• SERVFAIL: a resolver could not complete validation or resolution.
• REFUSED: the server deliberately rejected the query.
• NXDOMAIN: the name was reported as nonexistent.
• A network error such as connection refused, unreachable, or truncated response.

Local causes to investigate

• Local DNS service restart, crash, hang, or cache corruption. Check the system journal, Windows Event Viewer, or the logs for dnsmasq, Unbound, BIND, systemd-resolved, or the relevant security product.
• Router or gateway instability. Check WAN reconnects, DHCP renewals, PPPoE events, firmware logs, CPU or memory exhaustion, and whether the router’s DNS proxy stopped responding.
• DHCP or network-interface changes. A lease renewal, Wi-Fi roaming event, VPN connection, interface reset, or sleep/resume event may temporarily replace or remove the configured DNS servers.
• Firewall, endpoint security, or filtering software. DNS interception, parental-control filters, secure DNS clients, and VPN kill switches can block UDP or TCP port 53, or DNS-over-TLS/HTTPS traffic.
• Packet loss or MTU problems. DNS normally uses UDP, but larger responses may require TCP fallback. A path that drops fragmented packets or TCP/53 can cause selective failures.
• Resource exhaustion. Check for high connection counts, exhausted NAT state, low memory, CPU spikes, or a process generating excessive DNS requests.
• Local clock problems. Incorrect time usually affects DNSSEC validation and encrypted DNS more than ordinary DNS, and can produce SERVFAIL or certificate-related errors.
• DNSSEC or resolver-cache issues. A validating resolver can temporarily return SERVFAIL because of stale data, broken signatures, or an unreachable authoritative server.

Useful comparisons

Run tests against more than one resolver and record the result:

• dig example.com using the system-configured resolver.
• dig @your-router-address example.com to test the router’s DNS proxy.
• dig @1.1.1.1 example.com and dig @8.8.8.8 example.com to compare public resolvers.
• dig +tcp @resolver-address example.com to test TCP fallback.
• dig +dnssec example.com if DNSSEC-related failure is suspected.

tags are not XenForo BBCode? I should avoid unsupported? They said XenForo BBCode only, backticks prohibited, can use [CODE] maybe. Use [CODE] for commands? XenForo supports CODE. But tool? Let's continue plain [CODE]. Need no markdown. Also if only one domain versus all. Mention timestamps, packet capture. Could say if public resolver works but local doesn't local. If all resolvers fail from device but other network okay local path. If all devices and resolvers fail, upstream likely. Need not overstate. Need correct list source formatting maybe [*]. End conclusion. No question. Use URL perhaps docs? No need. Ensure no markdown. I accidentally internal only. Final clean. Also explain 20 min patterns: DHCP lease? DNS TTL no. ISP resolver maintenance, route flap, rate limits, authoritative outage. "internet backbone feature" phrase gently. Mention backbone feature not needed; DNS is distributed. Use commands with [CODE]. Good.- maybe dig uses @. Let's formulate.