Title: Ditching Bind9 for Unbound and Knot
Date: 2015-10-18 10:00

I was tired of using bind9 for my [DNS]( https://en.wikipedia.org/wiki/Domain_Name_System) because of its clunkiness,
its exhausting approach to [DNSSEC]( https://grepular.com/Understanding_DNSSEC ),
its awkward configuration format, its [bad security history](https://www.isc.org/community/blogs/)
(yes, it's the blog of the project, and almost every article is about a different vulnerability.),
its [future]( https://github.com/bundy-dns/bundy/pulse/monthly), and its archaism.

Since there is no good both authoritative *and* recursive DNS
server, I went with [unbound]( https://unbound.net/ )
and [knot]( https://www.knot-dns.cz/ ), both modern and lightweight.

# Unbound

![Unbound logo]({static}/images/unbound_logo.png)

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.

```yaml
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]( https://calomel.org/unbound_dns.html ),
because the only documentation available is the
[unbound.conf](https://unbound.net/documentation/unbound.conf.html) manpage.

# Knot

![Knot logo]({static}/images/knot_logo.png)

Knot is an authoritative-only DNS server,
written by (and for) [CZ.NIC]( https://www.nic.cz/page/351/ ), 
supports automatic DNSSEC signing, and has its configuration
(since version 2.0, packaged in Debian testing) in [YAML]( http://yaml.org/ ).

Here is my configuration for `dustri.org`:

```YAML
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:

```shell
$ 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]( https://www.icann.org/resources/pages/deployment-2012-02-25-en )
of course) about your public keys, 
and that's it, you have a [working DNSSEC configuration]( http://dnssec-debugger.verisignlabs.com/dustri.org )
on your zone, with automatic keys rotation!
You should also take a look at [RFC6781]( https://tools.ietf.org/html/rfc6781 )
about *DNSSEC Operational Practices*.

Currently, I'm publishing my webserver certificate with
[DANE]( https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities ),
which you can check with [this]( https://www.dnssec-validator.cz/ ) Firefox extension,
also from the wonderful [cz.nic](https://www.nic.cz/) people.

If you're feeling fancy, you can also [publish your ssh keys]( https://tools.ietf.org/html/rfc4255 ), 
and maybe soon your [GPG keys]( http://www.gushi.org/make-dns-cert/HOWTO.html ) too, over DNS.