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.
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
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.
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.
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.
hostname must correspond to the name in certificate (if using certificate authentication). That seems to be without the final dot in current practice.
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
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 Turris Documentation with clearing the cache and now everything works. https://dnsleaktest.com/ points to Cloudflare DNS. Before it could be some temporary error.
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?
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.
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…