Disabling the forwarding in foris/config/dns/ makes the name resolving very slow. I think it is because I don’t have the IPv6 connectivity. Disabling manually option net_ipv6 '0' in /etc/config/resolver makes it fast again.
I’ve measured the DNS response time by namebench on a Linux client:
Default option net_ipv6 '1': average 482 ms
Manual setting option net_ipv6 '0': average 25 ms
The manual setting comes from an old thread. Should not Knot resolver somehow automatically detect there is no IPv6 connectivity and use the IPv4? Or should not Turris set automatically the option net_ipv6 '0' for example when you hit the test button on foris/config/dns/ page and Turris knows, there is no IPv6 connectivity?
And last question, why the “forward” is the recommended option in foris/config/dns/? Is it just due to the performance? My ISP DNS has a problem with DNSSEC and I don’t like the idea of sending all my DNS requests to e.g. Google.
So I would recommend “forward” off for privacy and security. Moreover it seems the forwarding is actually not faster (although the numbers can vary due to the caching).
Manually switching option net_ipv6 '0': is currently the best approach I can recommend. (If you disable forwarding and don’t have working IPv6.)
I would personally prefer some solution around that foris/config/dns test. It’s not easy to detect reliably during runtime without a loss of latency, as there might be a temporary disconnect or lost packets, etc. So far knot-resolver does only per-IP tracking of latency and reliability.
Forwarding or not
I’d personally prefer to go without forwarding by default, assuming you want validation. It’s more reliable and closer to how the protocol was originally meant. If it’s a choice of forwarding to ISP’s server or not, both with DNSSEC validation, I can’t see a significant difference in security or privacy.
Security: signed records are validated either way, so no difference. Unsigned records go through similar paths either way, though there’s possibly a small difference – which resolver implementation is more resilient to spoofing attempts from outside the ISP’s network.
Privacy: all requests and answers go in cleartext either way. Outside the ISP’s network the requests are seen with the resolver’s IP, so in this sense forwarding may provide better privacy as requests of more users are sharing the same IP. On the other hand, forwarding probably makes it a tiny bit easier for the ISP to analyze where you connect to.
Speed: the difference is highly dependent on the particular network setup and the queries, IMHO. Note that local DNSSEC validation kills a part of the speed advantage of forwarding (maybe a significant one), because a single answer from a resolver won’t contain all information to verify the whole chain from the root (or to verify that the chain is broken at some point and the record is correctly unsigned).
Forwarding DNS requests to my ISP together with DNSSEC somehow fails to resolve some addresses, even though it worked approximately a week ago. Probably problem of my ISP as switching forward off or switching DNSSEC off solves it. I surely prefer forward off and DNSSEC on.
One Omnia user helped us to improve compatibility, so forwarding+validation will work in more cases soon, but I can’t estimate how big a fraction of users/ISPs that will be.