Artificial truth

archives | latest | homepage | atom/rss/twitter

The more you see, the less you believe.

Ditching Bind9 for Unbound and Knot
Sun 18 October 2015 — download

I was tired of using bind9 for my DNS because of its clunkiness, its exhausting approach to DNSSEC, its awkward configuration format, its bad security history (yes, it's the blog of the project, and almost every article is about a different vulnerability.), its future, and its archaism.

Since there is no good both authoritative and recursive DNS server, I went with unbound and knot, both modern and lightweight.

Unbound

Unbound logo

Unbound is a validating, recursive, and caching DNS resolver, with a simple configuration format and DNSSEC support.

This is my full configuration for a DNSSEC-enabled resolver for my LAN.

server:
        interface: 127.0.0.1
        interface: $MY_LAN_IP
        access-control: $MY_LAN_RANGE allow
        access-control: 127.0.0.1/24 allow

        auto-trust-anchor-file: "/var/lib/unbound/root.key"

        root-hints: "/etc/unbound/root.hints"

        do-ip4: yes
        do-ip6: no
        do-udp: yes
        do-tcp: yes

        # Unnecessary hardening
        hide-version: yes
        hide-identity: yes
        verbosity: 1
        harden-glue: yes
        harden-dnssec-stripped: yes
        use-caps-for-id: yes   
        prefetch: yes
        unwanted-reply-threshold: 10000
        val-clean-additional: yes

You can get more examples on Calomel, because the only documentation available is the unbound.conf manpage.

Knot

Knot logo

Knot is an authoritative-only DNS server, written by (and for) CZ.NIC, supports automatic DNSSEC signing, and has its configuration (since version 2.0, packaged in Debian testing) in YAML.

Here is my configuration for dustri.org:

server:
    listen: 195.154.14.189@53
    user: knot:knot
    rate-limit: 120
    rate-limit-slip: 1

log:
  - target: syslog
    any: info

template:
  - id: secure
    storage: /etc/knot/storage
    semantic-checks: on
    disable-any: on
    dnssec-signing: on

acl:
  - id: acl_gandi
    address: 217.70.177.40
    action: transfer

  - id: acl_rb
    address: 185.26.127.41
    action: transfer

remote:
  - id: rb
    address: A.B.C.D@53

  - id: gandi
    address: 217.70.177.40@53

zone:
  - domain: dustri.org
    template: secure
    acl: [acl_gandi, acl_rb]
    notify: [rb, gandi]

And this is how to initialize the DNSSEC-related cryptographic material:

$ cd $YOUR_CRYPTO_MATERIAL_FOLDER
$ keymgr init
$ keymgr policy add default_rsa algorithm RSASHA256 zsk-size 1024 ksk-size 2048 nsec3 true
$ keymgr zone add myzone.test policy default_rsa
$ dig dustri.org @127.0.0.1 +dnssec DNSKEY

You just have to tell your registrar (if it supports DNSSEC of course) about your public keys, and that's it, you have a working DNSSEC configuration on your zone, with automatic keys rotation! You should also take a look at RFC6781 about DNSSEC Operational Practices.

Currently, I'm publishing my webserver certificate with DANE, which you can check with this Firefox extension, also from the wonderful cz.nic people.

If you're feeling fancy, you can also publish your ssh keys, and maybe soon your GPG keys too, over DNS.