My Take on DNSSEC – Part 3: How to configure it in BIND (cancelled)

Just as a quick note here:
I originally planned to do my third part on DNSSEC with configuration hints using the popular DNS server BIND. At the moment I also use BIND for my setup.

Now I discovered the „Advanced Secuity Notifications“ at ISC, which sells prior warnings about security issues in BIND. Personally, I don’t want to support this model.

Instead I am currently migrating to another DNS server implemenation, YADIFA, which I will then write about. But first I need to check my setup using this server.

Update: Maybe I will switch to Knot DNS instead of YADIFA. They seem to be both fairly equal in features. To the outside spectator YADIFA seems to be a dead project, even though they published a release in mid-december. The development is done by EUnic, the guys behind maintaining the .eu-domain. They seem to have some internal development/issue tracking/etc. and they only send the releases to GitHub.
In contrast, Knot DNS, being maintained by cz.nic, is more open in their development.

My Take on DNSSEC – Part 2: How does it work?

As I already explained in Part 1, the current state of DNS is pretty insecure. The goal of DNSSEC is to improve this situation. Here is how that (should) work. I won’t go into cryptographic details here, but just show the general behaviour.

Lets have a look at the domain There is a DNS server responsible which provides some general records.

DNS Zone without DNSSEC recordsThere is no DNSSEC here and every record could be manipulated by an attacker.

Now we activate DNSSEC. To do so, we generate cryptographic keys and use these keys to sign the records in the zone. Let’s not talk about why we use multiple keys here. It would work with just one key, but we have reasons to use more than that. (The small green arrows in the images show existing signatures)

DNS zone with isolated DNSSEC signaturesNow this zone is signed by the DNSKEYs and every user could verifiy the signatures against the key. There is still a problem though. How can we trust the keys? The attacker could simply replace the keys and create his own „valid“ signatures.

To overcome this problem we need the cooperation of the „upstream“ domain, in this case „.de“. We publish the fingerprint of the first DNSKEY as a DS record in the TLD. The TLD uses its own key to sign this fingerprint. This leads to a trustworthy DNSKEY in our zone. But that only works if we have a way to trust the keys of the TLD.

DNSSEC secured zone with delegation to TLD Basically we are in the same situation as before, needing a way to verify the keys of the TLD. So we do the same as before and the TLD publishes the fingerprint in the parent root domain.

DNS zone with full DNSSEC hierarchyAnd again we are in the situation of needing to trust the root key. But now we don’t have any parent zone to publish the key fingerprint. The solution is pretty simple. We give everybody the fingerprint of the root key. Every piece of software that wants to verify the dnssec signatures is just preloaded with the root key. For example the bind DNS server has this part in the configuration:

        # ROOT KEY: See 
        # for current trust anchor information.
        # NOTE: This key is activated by setting 
        # "dnssec-validation auto;" in named.conf.
        . initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=";

Now we are able to verify all the records by following the signatures until we reach the root key.

This concludes the general mechanism of DNSSEC. In the next part we are going to have a more technical look on how to configure a DNS server to properly generate DNSSEC signatures and secure their zone.

My take on DNSSEC – Part 1: Why do I need that?

DNS [1] is probably one of the most important protocols on the internet. Everybody uses it countless times each day, usually without even noticing it. Every time somebody visits any website, every time somebody sends a mail, every time somebody wants to do literallly ANYTHING on the internet, a DNS server is involved.

What it does is fairly straightforward: It is a dictionary of domain names (like or and the associated IP address (like or 2001:DB8::12). If a user wants to access a website at a certain domain, the browser first queries a DNS server for the IP address  of the domain and then connects to the server with that address. Essentially it is a phonebook [2] for the internet.

Sadly the protocol is about as ancient as it can be in the internet, being developed in 1983. During these early days, nobody designed protocols to be protected against malicious attacks. For this reason DNS is horribly insecure and a largs-scale attack on the internet could probably render the entire internet unusable (for some time) [3]. But it can also be compromised in more subtle ways, i.e. directing users to wrong servers for phishing attacks.

To improve the situation, the DNSSEC protocol has been developed. It could be argued that DNSSEC is far from perfect [4] but at least it is a step in the right direction. For this reason I want to talk a bit about DNSSEC, what it does, how I use it on my server and how it can be used in clients.

But that will start in part 2