I’ve been trying to set up NextDNS on my Omnia and ran into an issue where NextDNS is unable to apply my custom DNS rules. NextDNS uses unique DoT hostnames to identify users’ configurations, but knot resolver does not seem to pass on the hostname at the start of the connection, and thus NextDNS does not identify my configuration. I believe this is because knot resolver does not support TLS Server Name Indication (SNI).
For those unfamiliar with NextDNS, it is essentially a cloud-hosted Pi-Hole; it allows fine grained control over DNS requests and can (optionally) log requests and provide analytics. To enable customization of dns and adblocking rules, NextDNS gives each configuration a unique ID that is incorporated into the IPv6 address (“2a07:a8c0::unique-id”), DNS-over-HTTPS URL (“https://dns.nextdns.io/unique-id”) or DNS-over-TLS hostname (“unique-id.dns.nextdns.io”). When using DoT, NextDNS relies on SNI to identify which configuration to apply.
I would appreciate any suggestions on how I might get NextDNS to work either via DoT or DoH, preferably in a way that is somewhat compatible with TOS and unlikely to break with future TOS updates.
For reference:
I’m on TOS 4 stable
The SNI issue is unique to DoT. I chose DoT because it is somewhat documented in the wiki.
NextDNS should work fine with DoH, but I have not found a way to set up DoH on Omnia.
Steps to reproduce:
Per resolver.conf README, create a 99_nextdns.conf in /etc/resolver/dns-servers with the following content:
Thanks for clearing this up so quickly! I thought I was running the latest stable release. Do you have a sense when 5.x will be stable? I’m reluctant to downgrade to 3.x or to upgrade to 5.x while it is still in beta. Thanks again.
Thank you both. I’ve upgraded to 5.0.0 but I’m afraid the error persists. Is there a particular setting to enable SNI? The resolver-conf documentation does not mention it.
The ID portion probably applies only for DoH. which kresd does not support in upstream connectivity, unless mistaken, and for DoT it is already stipulated
The question is whether the provider’s status page is capable to detect the subscriber ID deployed at the local resolver instance through the browser (script), if not it may print an incorrect status.
Filter testing might be better by trying to access/resolve any of the ads, trackers and malicious websites the service is supposed to be blocking with the subscription.
Yes, I haven’t mentioned it explicitly… there’s no planned support for DoH from kresd towards forwarders. And in Turris/OpenWrt there are currently even missing libraries needed for DoH server side, too.
The ID is actually also included in the IPv6 address. NextDNS uses the last two hextets of the IPv6 address as the ID (you can find an example config here).
I tried resolving some domains that should be blocked and I can confirm that the adblocking does not work.
Thanks. I read that as well. This is unfortunate because kresd also does not support ESNI (Encrypted Server Name Indication) so even if I could get SNI to work, the identifier included in the hostname is sent unencrypted.
ESNI standard isn’t even finished, so libraries often don’t support it yet. Some significant changes will happen to the protocol; I know about the new HTTPSSVC records for this (or whatever the final naming will be).
By the way… you use kresd as a client to connect to a single provider, so in these situations I can’t see much to hide by ESNI. Even generally you can estimate a lot just from the IP addresses that get contacted (that’s cleartext and very often the IP set is unique for the name) – and in this case I understand the IP even contains an ID specifically crafted for you (!)