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.
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.
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.
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).
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.
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!
@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.
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
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.
How long ago was that?