Categories
DNS Network Security

Fighting DNS hijacking with DNS over HTTPs/TLS

DNS-over-HTTPs/TLS is an up and coming technology that is slowly being adopted by different types of software, Firefox for example is beginning to enable it by default in their browsers with the DNS-over-HTTPs variant.

Whilst it has been met with some critism the advantages of finally being able to encrypt DNS queries is a good step towards internet privacy.

DNS hijacking used to be common with UK ISPs for returning targetted advertisements if a user typed in an non-existant domain. Later I found that an ISP was redirecting my search queries to their own hosted servers even though I had set my DNS servers to custom ones.

dnscrypt-proxy has been my goto fix for ensuring my DNS communications were untampered with for many years, but now I want to explore DOH (DNS over HTTPs) and DOT (DNS over TLS) to see if it fares any better.

I’m beginning by installing an application called stubby

sudo apt install stubby

On the manpage, Stubby is described as:

       ...a local DNS Privacy stub resolver, using DNS-over-TLS. Stubby encrypts DNS
       queries sent from the local machine  to  a  DNS  Privacy  resolver,  increasing  end  user
       privacy.

My goal is to install Stubby on my local DNS recursor server (running Ubuntu 18.04), and use it as a forwarded to securely resolve DNS queries.

It’s easy to tell that it’s my DNS server, as checking the service post-install shows it failed to start due to a port conflict:

stubby[5130]: error: Could not bind on given addresses: Address already in use

The configuration file looks to be in /etc/stubby/stubby.yml

First I want to fix the address bind error, so I find the section listen_addresses and add a custom port number at the end:

listen_addresses:
- 127.0.0.1@5353
- 0::1@5353

Save those changes, and restart the service with:

systemctl stubby restart

If I now check to see if the service is running, it appears that it is:

sudo systemctl status stubby
‚óŹ stubby.service - DNS Privacy Stub Resolver
Loaded: loaded (/lib/systemd/system/stubby.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2020-09-16 19:49:22 BST; 4s ago

Great, so we’ve got the Stubby application now running for DNS resolution on the DNS box only. It’s not yet serving pushing the requests from the rest of the network yet but thats still to come. For now I want to change away from the default servers that are included so I’ll look at changing that.

There is a good sized list of secured DNS Public Resolvers here:

https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Public+Resolvers

I commented out the list of existing servers, and added these three in to give them:

upstream_recursive_servers:
address_data: 1.1.1.1
tls_port: 853
tls_auth_name: "cloudflare-dns.com"
address_data: 1.0.0.1
tls_port: 853
tls_auth_name: "cloudflare-dns.com"
address_data: 9.9.9.10
tls_port: 853
tls_auth_name: "dns.quad9.net"

Let’s now change my DNS Recursor (pdns-recursor) to use 127.0.0.1:5353 and give it a try!

forward-zones-recurse=.=1.1.1.1

Changes to:

forward-zones-recurse=.=127.0.0.1:5353

Looking good!

Non-authoritative answer:
Name: amazon.com
Addresses: 176.32.98.166
176.32.103.205
205.251.242.103
And cloudflare seems happy too!