Name resolution takes forever

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).

Anyone? Any idea?

This is still present. I am tempted to reset the device and start over.

It is the very first query of any address! Meaning a single web page might do 10 or more lookups. It can take like 30 seconds to load a simple page because of it. Years later we still hear “probably your fault”.

Well, yes, knot-resolver caches results for their TTL interval, so the subsequent requests are answered immediately. That holds independently of forwarding/DNSSEC setting.

For any of you, gathering verbose logs from such a slow moment might shed light on the reason why it’s slow.

1 Like

Small update. This resolution delay i was having went away after moving my DNS config to the Foris interface and stopped using the Interface/WAN setting on Luci.

-J