Setting up your own DNSSEC-aware resolver using Unbound

Now that the root DNS servers are signed, I thought it was time I started using DNSSEC on my own PC. However, not wanting to wait for my ISP to enable it, I decided to setup a private recursive DNS resolver for myself using Unbound.

Installing Unbound

Being already packaged in Debian and Ubuntu, unbound is only an apt-get away:

apt install unbound ca-certificates

Optional settings

In /etc/unbound/unbound.conf.d/francois.conf, I enabled the following security options:

server:
    harden-below-nxdomain: yes
    harden-referral-path: yes
    harden-algo-downgrade: no # false positives with improperly configured zones
    use-caps-for-id: no # makes lots of queries fail
    hide-identity: yes
    hide-version: yes
    private-address: 10.0.0.0/8
    private-address: 100.64.0.0/10
    private-address: 127.0.0.0/8
    private-address: 169.254.0.0/16
    private-address: 172.16.0.0/12
    private-address: 192.168.0.0/16
    private-address: fc00::/7
    private-address: fe80::/10
    private-address: ::ffff:0:0/96
    module-config: "validator iterator" # disable EDNS client subnet support

and turned on prefetching to hopefully keep in cache the sites I visit regularly:

server:
    prefetch: yes
    prefetch-key: yes
    msg-cache-size: 128k
    msg-cache-slabs: 2
    rrset-cache-size: 8m
    rrset-cache-slabs: 2
    key-cache-size: 32m
    key-cache-slabs: 2
    cache-min-ttl: 3600
    num-threads: 2

Finally, I also restricted the server to the local machine:

server:
    interface: 127.0.0.1
    access-control: 0.0.0.0/0 refuse
    access-control: 127.0.0.1/32 allow

and increased the amount of debugging information:

server:
    val-log-level: 2
    use-syslog: yes
    verbosity: 1

before running sudo unbound-control-setup to generate the necessary keys.

Once unbound is restarted (sudo service unbound restart) stats can be queried to make sure that the DNS resolver is working:

unbound-control stats

Overriding DHCP settings

In order to use my own unbound server for DNS lookups and not the one received via DHCP, I added this line to /etc/dhcp/dhclient.conf:

supersede domain-name-servers 127.0.0.1;

and restarted dhclient:

sudo killall dhclient
sudo killall dhclient
sudo /etc/init.d/network-manager restart

If you're not using DHCP, then you simply need to put this in your /etc/resolv.conf:

nameserver 127.0.0.1

or on more recent distros, the following in /etc/systemd/resolved.conf:

[Resolve]
DNS=127.0.0.1
DNSSEC=no

Yes, you need DNSSEC=no because otherwise it will break insecure delegations and you'll see messages like this one in your logs:

systemd-resolved[1161]: DNSSEC validation failed for question dyn.fmarier.org IN SOA: no-signature

You can test that systemd-resolved is configured properly using:

systemd-resolve --status

Testing DNSSEC resolution

Once everything is configured properly, the best way I found to test that this setup was actually working is to use a web browser to visit these sites:

and using dig:

$ dig +dnssec A www.dnssec.cz | grep ad  
;; flags: qr rd ra <b>ad</b>; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 1

Are there any other ways of making sure that DNSSEC is fully functional?

Using DNS-over-TLS using Cloudflare's 1.1.1.1

In order to make use of DNS over TLS and effectively hide DNS queries from anybody looking at your network traffic, one option is to forward your queries to Cloudflare's 1.1.1.1:

server:
    tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt

forward-zone:
    name: "."
    forward-tls-upstream: yes
    # Cloudflare DNS
    forward-addr: 2606:4700:4700::1111@853#cloudflare-dns.com
    forward-addr: 1.1.1.1@853#cloudflare-dns.com
    forward-addr: 2606:4700:4700::1001@853#cloudflare-dns.com
    forward-addr: 1.0.0.1@853#cloudflare-dns.com

While Unbound appears to support DNS over TLS natively, it's not clear to me that it will connect to DNS servers over TLS while doing a recursive name resolution. Additionally, it will leak queries to non-encrypted servers to your ISP and other potential on-path attackers. Therefore, forwarding traffic to a non-logging trusted recursive resolver appears to be the best solution at the moment.

To test that DNS queries are being correctly forwarded to Cloudflare, use their official test page.

Integration with OpenVPN

If you are running your own OpenVPN server, you can tell clients to connect to the local unbound DNS client by putting the following in /etc/unbound/unbound.conf.d/openvpn.conf:

server:
    interface: 127.0.0.1
    interface: 10.8.0.1
    interface: 10.8.0.1@853
    access-control: 127.0.0.1 allow
    access-control: 10.8.0.1/24 allow

    tls-service-key: /etc/letsencrypt/live/hafnarfjordur.fmarier.org/privkey.pem
    tls-service-pem: /etc/letsencrypt/live/hafnarfjordur.fmarier.org/fullchain.pem
    tls-port: 853

and acquiring the necessary Let's Encrypt TLS certificates using Certbot. The DNS over TLS option is used automatically by certain VPN clients (e.g. Android) who will try to upgrade to secure DNS automatically.

If you are using AppArmor, then you'll need to put the following in /etc/apparmor.d/local/usr.sbin.unbound to ensure that Unbound can read the TLS cert it needs:

/etc/letsencrypt/archive/** r,
/etc/letsencrypt/live/** r,

and then run this:

apparmor_parser --replace /etc/apparmor.d/usr.sbin.unbound

Then put the following in /etc/openvpn/server.conf:

push "dhcp-option DNS 10.8.0.1"
push "register-dns"

and open the following ports on your firewall (typically /etc/network/iptables.up.rules on Debian):

-A INPUT -p udp --dport 53 -s 10.8.0.0/24 -d 10.8.0.1 -j ACCEPT
-A INPUT -p tcp --dport 53 -s 10.8.0.0/24 -d 10.8.0.1 -j ACCEPT
-A INPUT -p tcp --dport 853 -s 10.8.0.0/24 -d 10.8.0.1 -j ACCEPT

before restarting both services:

systemctl restart unbound.service openvpn.service

Work-around for systemd-networkd

If you're having problems with unbound attempting to start before systemd-networkd has finished bringing up the network interfaces, then you may find this work-around useful.

Start by installing these packages:

apt install networkd-dispatcher moreutils

and then put the following script in /etc/networkd-dispatcher/routable.d/unbound-local:

#!/bin/sh

LOGFILE=/var/log/unbound-local.log

if [ "$IFACE" = lo ]; then
    echo "$0: ignoring $IFACE for \`$STATE'" | ts >> $LOGFILE
    exit 0
fi

case "$STATE" in
    routable)
        echo "$0: restarting unbound because of $IFACE" | ts >> $LOGFILE
        systemctl stop unbound.service 2>&1 | ts >> $LOGFILE
        sleep 5 # hack around unbound's rate limiter
        systemctl start unbound.service 2>&1 | ts >> $LOGFILE
        ;;
    *)
        echo "$0: nothing to do with $IFACE for \`$STATE'" | ts >> $LOGFILE
        ;;
esac

exit 0

before making it executable:

chmod a+x /etc/networkd-dispatcher/routable.d/unbound-local

Finally, create a new /etc/logrotate.d/unbound-local file to ensure that the log file does not grow unbounded:

/var/log/unbound-local.log {
        monthly
        rotate 1
        nocreate
        nomail
        noolddir
        notifempty
        missingok
}
Freedom in the Cloud Miniconf at linux.conf.au 2011

Jon Phillips and I are putting together a Freedom in the Cloud Miniconf for linux.conf.au 2011.

If you are interested in submitting a proposal (5, 25 or 45 minutes), we want to hear from you!

The deadline is 22 October 2010.

Whether or not 2011 will be known as the year of the Federated Social Web remains to be seen, but the cloud is certainly not going away and we'd like to propose a Miniconf to cater to all cloud enthusiasts.

Specifically, we'd like to solicit proposals from two main groups. The first one is the hard-core technical cloud engineers who build their tech on Open Source software. The kind of people who know so much about tweaking their kernels and scaling their infrastructures that they could out-Google Google.

Possible topics could include: cloud storage, virtualization, high availability, security, cloud performance and infrastructure management.

The second group of people we'd like to attract are the free network services and federated social web people. These folks know that the growth of netbooks and smartphones has meant a great dependence on centralized network services. But as more and more computing moves into "the cloud", users and companies are losing direct control over their data and processes. They see a very high risk to businesses and individuals.

This group would cover ways that individuals and organizations can ensure that their cloud computing is as dependable and freedom-respecting as running Open Source software on computers they own and control. They will concentrate on using Open Source, Open Data, and Open Standards to keep control in the hands of cloud computing users.

Speakers will vary from theoretical discussions about Free network services; developers of Free and federated alternatives to popular centralized cloud services; and tutorials on how to build an Open Source cloud network that you and your business can depend on.