Using dns over tls or https

With the recent announcement of a (they say) privacy oriented DNS server at Cloudflare (it was announced on April 1, so IDK, maybe it’s a joke, but it doesn’t seem to be), I became interested in this as a further method for improving privacy.

Additionally, in my reading, some ISPs do DNS cache poisoning regardless of whether you use a different DNS server. I thought DNSSEC should mitigate this? It looks like Google’s DNS over HTTPS provides DNSSEC as well. No mention whether Cloudflare does DNSSEC.

I’m wondering, if kresd doesn’t support dns over https, will it support it at some point in the future?

Meanwhile. . . There is a https_dns_proxy package available which is configured by default to use Google’s DNS servers plus some others. Of course, Cloudflare offers their own at 1.1.1.1.

I’ve set up in the https_dns_proxy package in Omnia and it looks like once https_dns_proxy is started, I would only need to set option dns '127.0.0.1#5053'in /etc/config/network. Since this would be a change in the network config, will I need to restart the network /etc/init.d/network restart?
Is restarting the resolver the only thing that needs to happen /etc/init.d/resolver restart.

I could just edit /tmp/resolv.conf (in my case). If you’re using the default, /tmp/resolv.conf.auto

Since my resolv.conf only contains 127.0.0.1 as a nameserver I assume that kresd has built it’s own cache by going to the root servers. Is this an incorrect assumption? Or does kresd use /tmp/resolv.conf.auto in spite of /etc/resolv.conf pointing to /tmp/resolv.conf which sits on it’s own (is not linked to /tmp/resolv.conf.auto).

While DNSSEC ensures integrity of data between a resolver and an authoritative server, it does not protect the privacy of the “last mile” towards you. DNS resolver like 1.1.1.1, supports both emerging DNS privacy standards - DNS-over-TLS and DNS-over-HTTPS, which both provide last mile encryption to keep your DNS queries private and free from tampering. The former standard will be supported by kresd, but I didn’t know the implementation status on turris devices.

http://knot-resolver.readthedocs.io/en/stable/modules.html

TLS_FORWARD({{ip, authentication}}) - resolve a query via TLS connection forwarding to an IP while validating and caching locally; the parameter can be a single IP (string) or a lua list of up to four IPs.

Unbound features DNS-over-TLS too and without the restraint of four IPs

1 Like

Looking up the knot-resolver documention, I attempted to add the following ot my custom.conf file:

-- DNS over TLS
policy.add(policy.all(policy.TLS_FORWARD({{'1.1.1.1@843', pin_sha256='Wg=='}}) -- < did not work
policy.add(policy.all(
      policy.TLS_FORWARD({ 
          {'1.1.1.1@843', hostname='cloudflare-dns.com.'} 
      })
)) -- < also did not work.

I’m not sure what else to try here.
Two things that I didn’t really understand in the documents.

First, policy.TLS_FORWARD({{'192.0.2.1', pin_sha256='YQ=='}})
I don’t understand what 'YQ=='is for. There’s no real explanation for it other than pin_sha256 is base64-encoded. This is some sort of code/key given by the site that has to be base64-encoded?

Second, the examples given also have a ca_file='<somefile>' option added to the hostname version. I downloaded the cert file for cloudflare-dns.com and added that

policy.add(policy.all(
      policy.TLS_FORWARD({ 
          {'1.1.1.1@843', hostname='cloudflare-dns.com.', ca_file='/etc/kresd/cloudflare.crt' }
      })
)) -- < also did not work.

Any other ideas?

  1. Version: for TLS forwarding you need knot-resolver >= 2.0.0. Stable Omnia has 1.5.x ATM, if I look correctly, but Omnia RC should have new enough already.
  2. Pin: it’s something like a hash of the TLS key. The service may publish it, but you’ll have to update it on key rotations. You probably want to use certificates instead, like regular https.
  3. hostname must correspond to the name in certificate (if using certificate authentication). That seems to be without the final dot in current practice.

This config works for me:

policy.add(policy.all(
      policy.TLS_FORWARD({
          {'1.1.1.1', hostname='cloudflare-dns.com', ca_file='/etc/ssl/certs/ca-certificates.crt' }
      })
))

Well, I only tried it on my desktop, but these things tend not to differ.

4 Likes

When will 2.0.0 be included in stable branche?

I don’t know an estimate/plan. It’s in 3.10 RC, apparently, so the question belongs into that thread.

I would be really great to have DNS-over-TLS option directly in Foris on DNS page.

5 Likes

Privacy-Protecting Portable Router: Adding DNS-Over-TLS support to OpenWRT (LEDE) with Unbound

We have a thread already: Using dns over tls or https

In case anyone else is trying to get this to work, I had a few problems settings things up myself, but I have now finally got it to work.
First of all, you have to set forward_upstream to 0 in /etc/config/resolver under common. Not doing this will cause it to still forward DNS queries to whatever servers you get from your ISP.
Secondly, the ca_file should not be the certificate from cloudflare-dns.com, instead it should be the certificate that authored it, which is “DigiCert ECC Secure Server CA”. You can download this cert from: https://www.digicert.com/CACerts/DigiCertECCSecureServerCA.crt. Knot-resolver doesn’t seem to support DER, so make sure you convert it to PEM:
openssl x509 -inform der -in DigiCertECCSecureServerCA.crt -out DigiCertECCSecureServerCA.pem

2 Likes

It’s about Android and not Omnia, but let me post a link: https://android-developers.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html

Ok so:

I just did that. How do I verify if it works (wireshark?)? And what about 1.0.0.1 can I just set another rule with the second ip?

EDIT: I reverted the changes since it breaks lxc-create -t download -n container_name functionality with:
Setting up the GPG keyring
ERROR: Unable to fetch GPG key from keyserver.
lxc-create: lxccontainer.c: create_run_template: 1201 container creation template for container_name failed
lxc-create: lxc_create.c: main: 274 Error creating container container_name
Discovered by accident

EDIT2:
I followed https://doc.turris.cz/doc/en/public/dns_knot_misc with clearing the cache and now everything works. https://dnsleaktest.com/ points to Cloudflare DNS. Before it could be some temporary error.

1 Like

Hi,
is this adaptation still necessary if knot resolver has appeared in version 2.0.0? So with the release of TurrisOS 3.10? Or is that easier to adjust?

Best regards

It’s impossible to forward over TLS with knot-resolver < 2.0.0, i.e. the default version with Omnia < 3.10. I don’t expect Omnia would have some clickable way to set this up as of 3.10.x already, but I don’t follow this side closely. @paja should know.

Hi,
yes our plan is to introduce DNS-over-TLS setting in future Foris version (probably 3.10.x or 3.11 TurrisOS)

6 Likes

For those ones using RC and having setup DNS over TLS: are DNS-queries speeds really that fast as advertised by cloudflare?

I think the numbers will be significantly affected by your particular ping to their IPs. (In CZ they have servers in Prague.)

1 Like

Where exactly do I add the policy-section you mentioned above?

See the wiki. I expect you also need to uncheck forwarding in Foris, as that would normally result into a different forwarding rule before the one added by you (and thus taking precedence); combining config pieces from different sources is just hard to do generally…

1 Like