# DNS queries timing out

## Hamlet

I have a problem with the name resolution service. The problem has started suddenly on a previously working system (I update it periodically, but I would not know how to identify a suspicious update):

 Vivaldi browser gives me a `DNS_PROBE_FINISHED_BAD_CONFIG`, a `DNS_PROBE_FINISHED_NXDOMAIN` or similar, more often than not

 Kerberos 5 client often fails to get me a Kerberos ticket

 SSH often can't establish a connection to remote servers

 `emerge --sync` takes some tries to find a server

 etc.

My connection has a cable modem connected to a router, connected to a OSX laptop and a Linux desktop (where the problem is) via local Ethernet, plus some other wireless devices.

The Linux desktop and the OSX laptop are both connected via LAN, both refer to the DNS 8.8.8.8 (secondary 8.8.4.4), referral which I believe comes from the Internet provider. Only the former manifests the problem above.

Pinging the DNS (in fact, even flooding it -- I apologise) does not lose any packet.

Wireshark shows me that when I query the DNS, quite a number of questions are submitted, and typically a few of them do not see any answer; each failure is followed by 5 seconds of timeout and then a retry.

`resolvectl` is very patient and waits, but the rest of the clients (most notably, the browser) give up pretty quickly.

Here is a spectacular 42 s query of `www.wikipedia.com`:

```
No.  Time           Source       Destination  Protocol Length Info

  51 65.896479279   192.168.1.2  8.8.4.4      DNS      111    Standard query 0x54f2 AAAA www.wikipedia.com OPT

  52 65.896615624   192.168.1.2  8.8.4.4      DNS      111    Standard query 0x36e0 A www.wikipedia.com OPT

  68 71.123506666   192.168.1.2  8.8.8.8      DNS      111    Standard query 0x54f2 AAAA www.wikipedia.com OPT

  69 71.123629403   192.168.1.2  8.8.4.4      DNS      111    Standard query 0x36e0 A www.wikipedia.com OPT

  72 76.373471171   192.168.1.2  8.8.8.8      DNS      111    Standard query 0x54f2 AAAA www.wikipedia.com OPT

  73 76.373595839   192.168.1.2  8.8.4.4      DNS      111    Standard query 0x36e0 A www.wikipedia.com OPT

  74 76.463031722   8.8.8.8      192.168.1.2  DNS      116    Standard query response 0x54f2 AAAA www.wikipedia.com AAAA 2620:0:863:ed1a::1 OPT

  75 76.463299593   192.168.1.2  8.8.4.4      DNS      111    Standard query 0xfbf8 SOA www.wikipedia.com OPT

  76 76.634459989   8.8.4.4      192.168.1.2  DNS      152    Standard query response 0xfbf8 SOA www.wikipedia.com SOA ns0.wikimedia.org OPT

  77 76.634706117   192.168.1.2  8.8.4.4      DNS      107    Standard query 0x8bfe DS wikipedia.com OPT

  78 76.634832638   192.168.1.2  8.8.4.4      DNS      111    Standard query 0xf28a DS www.wikipedia.com OPT

  79 76.672042886   8.8.4.4      192.168.1.2  DNS      805    Standard query response 0x8bfe DS wikipedia.com NSEC3 RRSIG SOA a.gtld-servers.net RRSIG NSEC3 RRSIG OPT

  80 76.672308732   192.168.1.2  8.8.4.4      DNS      97     Standard query 0xffa8 DNSKEY com OPT

  81 76.686307119   8.8.4.4      192.168.1.2  DNS      785    Standard query response 0xffa8 DNSKEY com DNSKEY DNSKEY RRSIG OPT

  82 76.686556909   192.168.1.2  8.8.4.4      DNS      97     Standard query 0x7be5 DS com OPT

  83 76.697220813   8.8.4.4      192.168.1.2  DNS      409    Standard query response 0x7be5 DS com DS RRSIG OPT

  84 76.697452035   192.168.1.2  8.8.4.4      DNS      93     Standard query 0xae72 DNSKEY <Root> OPT

  85 76.710338907   8.8.4.4      192.168.1.2  DNS      1456   Standard query response 0xae72 DNSKEY <Root> DNSKEY DNSKEY DNSKEY DNSKEY RRSIG OPT

  86 76.805754622   8.8.4.4      192.168.1.2  DNS      152    Standard query response 0xf28a DS www.wikipedia.com SOA ns0.wikimedia.org OPT

  87 76.806009410   192.168.1.2  8.8.4.4      DNS      107    Standard query 0xbf6d SOA wikipedia.com OPT

  88 76.879904179   8.8.4.4      192.168.1.2  DNS      148    Standard query response 0xbf6d SOA wikipedia.com SOA ns0.wikimedia.org OPT

  89 81.623492440   192.168.1.2  8.8.8.8      DNS      111    Standard query 0x36e0 A www.wikipedia.com OPT

  90 86.873321374   192.168.1.2  8.8.4.4      DNS      111    Standard query 0x36e0 A www.wikipedia.com OPT

  94 92.123468898   192.168.1.2  8.8.8.8      DNS      111    Standard query 0x36e0 A www.wikipedia.com OPT

  95 97.373317730   192.168.1.2  8.8.4.4      DNS      111    Standard query 0x36e0 A www.wikipedia.com OPT

  96 102.623480148  192.168.1.2  8.8.8.8      DNS      111    Standard query 0x36e0 A www.wikipedia.com OPT

  97 107.873317967  192.168.1.2  8.8.4.4      DNS      111    Standard query 0x36e0 A www.wikipedia.com OPT

  98 107.961115779  8.8.4.4      192.168.1.2  DNS      104    Standard query response 0x36e0 A www.wikipedia.com A 198.35.26.96 OPT

```

OSX issues, in comparison, a single query ("Standard query 0x0426 A www.wikipedia.com OPT").

The local DNS cache (`resolvectl statistics`) clears quick and misses often, even after repeated `resolvectl query` queries for the same address.

Is this failure rate normal? is it my timeout unreasonably high? (a successful query takes a few tenth of a second) If so, where is that timeout controlled in my systemd/dhcpcd platform?

Any other suggestion?

----------

## turtles

Those AAAA requests are ipv6

Do you really have an ipv6 nameserver?

My guess is your ipv6 DNS requests have top priority then requests are timing out and your system falls back to ipv4, which is all most networks have.

Another handy one is 

```
/usr/sbin/tcpdump -vvv -s 0 -l port 53
```

Check out /etc/gai.conf 

ipv6 is rarely used but once was thought to be replacing ipv4 'soon' that was 20 years ago. It probably slows down more Gentoo systems than anybody realizes.

Unless your running a Gentoo router or know your system needs ipv6 I would get rid of it.

I now disable the USE flag 

```
-ipv6
```

 in my make.conf these days . 

A few packages "need it" like net-dialup/ppp and I enable it on a per package basis.

Some other packages need it in the kernel (but not enabled) So I keep compiling it in as modules.

 /etc/default/grub 

```
GRUB_CMDLINE_LINUX="ipv6.disable=1"
```

Hope that helps

Cheers

----------

## Hamlet

I tried with "-ipv6" and killing IPv6 support from the kernel, but it did not seem to help.

Thank you for the hint, though, and for your thoughts on IPv6. It seems now to be more of a presence than it used to be, but I might be better off without it for the time being anyway.

I had this problem for two weeks, making navigation almost impossible. A few days ago, it went back to normal. Why? no clue.

Probably I'll whine and reopen the case in another two weeks, when it will be come back...

----------

