Name resolution takes forever

DNS name resolution takes forever.

I am talking about multiple seconds to resolve a single domain.

What I tried so far:

  • turn DNS forwarding on/off in forris
  • set DNS nameservers to 9.9.9.9 and 2620:fe::fe (the new quad9.net ones) plus the good old 8.8.8.8 (they do not seem to appear in /etc/resolv.conf though)

I am lightly confused on how dnsmasq and knot gear into this, as well as when the DNS I put in are actually are used.

In a perfect world I would give a set of nameservers somewhere and cache their results, but I am not sure how this is done with knot and dnsmasq at the same time.

The fallout:

  • Mac OS X HIgh Sierra takes forever (10sec and up to resolve on browser open)
  • Linux takes a few seconds for the initial resolve

Any hints? Any ideas? @vcunat I guess that is your territory? Any support would be much appreciated.

1 Like

First I assume this is Omnia, using knot-resolver for DNS (that’s the default). In that setup, dnsmasq does only DHCP and not DNS.

With a completely erased DNS cache, the first query may be slow with DNSSEC on, but ~10 s seems too much even in that case, on decent internet connection. Also, I assume it happens more often than on the very first query, right?

If you set DNS nameservers in Foris/WAN, that will be the servers that knot-resolver will query to answer DNS stuff if forwarding is enabled. In particular anything in the network should keep asking Omnia for DNS (/etc/resolv.conf, etc.) and not those servers directly.

First, what does the diagnostics in Foris/DNS show? I generally prefer to have forwarding off, and it’s the simpler case, so we would better start debugging in that mode.

Hi,
you could try to put following line into /etc/resolv.conf

options single-request

It seems that recent glibc versions on Linux (Debian) need this option to work correctly at least with turris/unbound.

Petr

Can you provide some link/evidence? My quick search found nothing.

OP still hasn’t clarified whether it’s Turris 1.x or Omnia (i.e. defaults: Unbound or Knot-resolver).

No link or anything. I had this strange problem and did stumble on this option somewhere. Without it it would send first request and ignore the reply and after 5s sends another DNS request. This time only for single record and it works.

I didn’t investigate further.

Turris 1.0 + Debian unstable

Oh :frowning: How long ago was that?

Yes it is Turris Omnia Default setup regarding dnsmasq and knot.

https://screenshots.firefox.com/4wMEYjBHW3IW6mKg/192.168.1.1

Note that the IPv4 resolving fails due to the my ds-lite setup, practically IPv4 works just fine. ( The configuration is depicted under Ds-lite / dslite IPv4 connection not working, IPv6 working fine - first post)

Under fedora 27:

$ man resolv.conf

          single-request (since glibc 2.10)
                 Sets  RES_SNGLKUP in _res.options.  By default, glibc performs IPv4 and IPv6 lookups in parallel since version 2.9.  Some appliance DNS servers cannot handle these queries properly and
                 make the requests time out.  This option disables the behavior and makes glibc perform the IPv6 and IPv4 requests sequentially (at the cost of some slowdown of the resolving process).

Hi,

since version 3.8.5/6 I also had problems with the DNS query. Curiously, only on iOS devices. The DNS request took forever and finally there was an annoying timeout. However, no problems on the Mac/PC.

Since I also only have the default configuration (KNOT with DNSSEC, Turris Omnia) active, I was wondering why it doesn’t affect other users as well. It was really quite here in the board.

Internet access is via LTE (O2 Telefonica network), which does not yet support IPv6. Perhaps this could be the reason for this too?

@cech: Thank you! With options single-request it actually works without any problems.

Is that the solution or just a workaround?

I got around to make the change on 10th October. I think I had this behavior some months before that, but never got around to “fix” it.

To be sure, you set the option on those iOS devices, right? That would be against the glibc-bug assumption.

No, I adjusted it on the Turris Omnia in /etc/resolv. conf!

For all iOS devices connected to the Omnia via WiFi, I had the problem that a DNS timeout occurs after a few seconds.
The error is also reproducible. Without the option DNS just won’t work on those devices!

I had the same problem as I bought the router.
I tried quite a lot to fix it but the solution was to disable dnssec and set dns forwarding to the one of my ISP. Since then everything works fine.
Today I use pihole in between and everything is still working without problems.
I hope that helps!

I have the same problem. Started about two month ago?
Turning on forwarding and disabling DNSSEC works for me too.

I think it might by because my ISP does not support IPv6 and the clients/local resolver tries ipv6 first.

@vcunat this seems to be a more widespread issue than I expected, though I am not so sure these are all the same issues or if client side name resolution behaviour matters too.

What exactly can I provide to you? Would wireshark traces of the DNS lookups help you?

I have a similar issue here on an up-to-date arch linux machine and : Turris OS 3.8.6 on the router. DNS resolving problems since a week or so (after a system update). No clue what’s going on. Might have something to do with systemd-resolved.

I have now managed to install resolver-debug on my turris omnia as decribed here “Debugging DNS problems on Omnia

Will try to extract some useful debugging info and post it here.

The DNS issue seems related to my local network setup: I am connected to the wider internet via a FritzBox with local address 192.168.178.1 and the Turris Omnia connected as 192.168.178.20.
My Arch Linux system is behind the Turris Omnia and sees the Turris Omnia as 192.168.1.1. The Arch Linux machine has IPv4 address 192.168.1.164

In the status overview I see

IPv4 WAN Status
eth1 Type: dhcp
Address: 192.168.178.20
Netmask: 255.255.255.0
Gateway: 192.168.178.1
DNS 1: 192.168.178.1
Expires: 9d 23h 42m 30s
Connected: 0h 17m 30s

IPv6 WAN Status
eth1 Address: 2001:985:d31:1:da58:d7ff:fe00:43f0/64
Gateway: fe80::9ec7:a6ff:fec7:cbcb
DNS 1: fd00::9ec7:a6ff:fec7:cbcb
Connected: 0h 17m 5s

I have the impression that when switching from a wired connection via the Turris Omnia to a WIFI connection via the Fritzbox (as 192.168.178.22 – my Turris Omnia does not provide WIFI) these IPv4 and IPv6 statuses get messed up.

So I am wondering if I need to adapt my DHCP and DNS settings to handle this dual reality.

Probably I also need to learn more about local networks and subnets… Any suggestions on where I can read up on this issue are most welcome.

We are probably mixing multiple different DNS-related issues here.

@erikwesselius: I personally consider having multiple network ranges (and DHCP servers) an unnecessary complication in “SOHO” networks, in particular layering one 192.168.x.y in another… but I’m certainly no expert on this (and it would better be moved into a separate thread anyway).

IPv6

It’s true there were sometimes extra latencies if IPv6 didn’t really work and wasn’t explicitly disabled in knot-resolver configuration, because of time repeatedly spent waiting on packets that ultimately don’t arrive. For about two months, this should be mitigated by an automatic check 15s after resolver starts, though I suppose that check might fail in some setups (e.g. if the connection doesn’t get up within 15s for some reason). There’s no relation to DNSSEC, except that getting information necessary for validation requires sending more packets in some cases.

I’m very doubtful about that – if DNS served by Omnia goes through libc’s resolver on Omnia (for Omnia’s resolv.conf to have any effect), something must be seriously misconfigured. Normal knot-resolver setup can’t do that (not sure it’s even easily possible on Omnia). For @cech’s answer it seems not explicitly stated on which machine the file was edited.

@vcunat the issue still pertains. There is one device in my network which - for the first time only - takes for ever to resolve an url.

Is there anything I can try? Would a tcp dump help (I guess so).