DNS-over-TLS forwarding to custom NextDNS fails due to (apparent) lack of SNI in knot-resolver

#1

Hi everyone,

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:

    name=“99_nextdns.conf”
    description=“NextDNS”
    enable_tls=“1”
    port=“853”
    hostname=“id redacted.dns.nextdns.io”
    ipv4=“45.90.28.227 45.90.30.227”
    ipv6=“2a07:a8c0::id redacted ea:af24 2a07:a8c1::id redacted”
    pin_sha256=“n9IhR0/BaHVicvPKHGUMi7haQ9CFg3fOzLBFZP4NlMU=”
    ca_file="/etc/ssl/certs/ca-certificates.crt"

  • Enable the new NextDNS entry as DNS Forwarder under the DNS tab in Foris.

  • Visit my NextDNS page and see the following message:

    This device is using NextDNS with no configuration.
    Make sure you use the DNS-over-TLS endpoint shown below.

#2

Turris OS 4.x contains an old version of Knot Resolver that didn’t send SNI yet. On 5.x it’s new enough (and on stable 3.x as well). https://forum.turris.cz/t/turris-os-5-0-0-is-released-in-hbt

1 Like
#3

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.

#4

I don’t really know more about Turris 5.x timing than what’s posted in there.

#5

If you are confused, upgrade to TOS 5 (HBT) with current security updates. TOS 4 is abandoned and upgrade is easier then downgrade.

#6

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.

#7

No, SNI should always get sent when hostname is set.

#8

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.

#9

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.

#10

It seems there is some DoH integration provided with dnsmasq as resolver https://github.com/openwrt/packages/tree/openwrt-19.07/net/nextdns

#11

Thanks for your suggestions.

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.

#12

Is that the name server for the paying subscribers? Their documentation states repeatedly (in the router section)

dns1.nextdns.io   
dns2.nextdns.io

Also the IP addresses are different.

Annotation 2020-05-23 004038
Annotation 2020-05-23 0040381024×568 63.8 KB

#13

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 (!)