While there is real progress being made towards eliminating insecure HTTP traffic, DNS is a fundamental Internet service that still usually relies on unauthenticated cleartext. There are however a few efforts to try and fix this problem. Here is the setup I use on my Debian laptop to make use of both DNSSEC and DNSCrypt.
DNSCrypt
DNSCrypt was created to enable end-users to encrypt the traffic between themselves and their chosen DNS resolver.
To switch away from your ISP's default DNS resolver to a DNSCrypt resolver,
simply install the dnscrypt-proxy package and then
set it as the default resolver either in /etc/resolv.conf:
nameserver 127.0.2.1
if you are using a static network configuration or in
/etc/dhcp/dhclient.conf:
supersede domain-name-servers 127.0.2.1;
if you rely on dynamic network configuration via DHCP.
There are two things you might want to keep in mind when choosing your DNSCrypt resolver:
- whether or not they keep any logs of the DNS traffic
- whether or not they support DNSSEC
I have personally selected a resolver located in Iceland by setting the
following in /etc/default/dnscrypt-proxy:
DNSCRYPT_PROXY_RESOLVER_NAME=ns0.dnscrypt.is
DNSSEC
While DNSCrypt protects the confidentiality of our DNS queries, it doesn't give us any assurance that the results of such queries are the right ones. In order to authenticate results in that way and prevent DNS poisoning, a hierarchical cryptographic system was created: DNSSEC.
In order to enable it, I have setup a local unbound DNSSEC
resolver
on my machine and pointed /etc/resolv.conf (or
/etc/dhcp/dhclient.conf) to my unbound installation at 127.0.0.1.
Then I put the following in /etc/unbound/unbound.conf.d/dnscrypt.conf:
server:
# Remove localhost from the donotquery list
do-not-query-localhost: no
forward-zone:
name: "."
forward-addr: 127.0.2.1@53
to stop unbound from resolving DNS directly and to instead go through the encrypted DNSCrypt proxy.
Reliability
In my experience, unbound and dnscrypt-proxy are fairly reliable but they eventually get confused (presumably) by network changes and start returning errors.
The ugly but dependable work-around I have found is to create a cronjob at
/etc/cron.d/restart-dns.conf that restarts both services once a day:
0 3 * * * root /usr/sbin/service dnscrypt-proxy restart
1 3 * * * root /usr/sbin/service unbound restart
Captive portals
The one remaining problem I need to solve has to do with captive portals. This can be quite annoying when travelling because it requires me to use the portal's DNS resolver in order to connect to the splash screen that unlocks the wifi connection.
The
dnssec-trigger package
looked promising but when I tried it on my jessie laptop, it wasn't
particularly reliable.
My temporary work-around is to comment out this line in
/etc/dhcp/dhclient.conf whenever I need to connect to such annoying wifi
networks:
#supersede domain-name-servers 127.0.0.1;
If you've found a better solution to this problem, please leave a comment!
FWIW, my usual solution to captive portals is to add some exceptions to the DNS resolution/HTTP proxy, which forces enough requests to go "directly" to be able to log into the captive portal. Eg, the domain of the place I'm staying in, and the domain of whatever Wifi provider they're using. Then I trigger the captive port by, eg, trying to go to the domain of the place I'm staying in. Over time one could accumulate a list of such exceptions required (and it seems like something that could be crowd sourced).
For better privacy one would perhaps want to selectively enable these exceptions based on the current location (and/or selectively disable them if at known locations like home/work/etc when it's not needed).
Ewen
PS: If your names are resolved from a location far away from you, you'll also generally get CDN nodes which are far away from you. Which may lead to poor performance. YMMV.
I don't believe that
dnsproxy-cryptcaches (the name implies it doesn't), but Unbound does.There's some documentation on https://wiki.debian.org/HowTo/dnsmasq
Unfortunately this setup still leaks the client IP address to the resolver. There's no way to use dnscrypt over Tor yet: https://github.com/jedisct1/dnscrypt-proxy/issues/234
Why encrypt DNS when your browser still leaks the domain name via SNI extension, even though it runs over https? https://wikipedia.org/wiki/Server_Name_Indication
I'm doing a lot of business trips so I'm using a lot of Airport and Hotel WiFis. So far I could reach all the captive portals when directly typing http://1.1.1.1 into my browser address bar. I don't know if this a standard but so far it seems all the captive portals are reachable this way. If it won't work I would have a look at the IP DHCP gave, e.g. 192.168.10.42, and then would try to acces 192.168.10.1 (but I never needed to try this as 1.1.1.1 always worked for me).
Hallo!
How do you manage that dnscrypt-proxy is set up to operate on 127.0.2.1? On Debian 11 it is set to 127.0.0.1, and I yet have to find a way to change it.