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

Installing pyLoad on a Raspberry Pi with Raspbian Jessie

If you are anything like me [1], you like to have dedicated Services which do stuff for you. One of the Services I like in particular is pyLoad [2]. This program you be used to automatically load files from OneClick Hosters. This is esspecially useful if you run this on a small computer like the Raspberry Pi [3] and dump the downloaded data to a central Storage like a NAS.

There are lots of blogposts out there which detail how to install pyLoad on a RaspberryPi [4][5][6]. For most parts I don’t really want to say anything against these, but there was one point in particular that I dislike about all of these. This is the reason why I am now writing my own guide. So let’s get started.

„Installing pyLoad on a Raspberry Pi with Raspbian Jessie“ weiterlesen

Umstellung von Apache auf Nginx

Statt nur das Serverzertifikat zu wechseln habe ich gleich auch den Webserver von Apache auf Nginx umgestellt. Dabei interessiert mich die angebliche bessere Performance nur nebenbei, mir ging es um die bessere Unterstützung von TLS Ciphers. „Umstellung von Apache auf Nginx“ weiterlesen

Apple und TLS

Auf dem 30C3 habe ich festgestellt, dass meine Homepage auf Apple Geräten nicht geladen wurde. Es wurde eine Verbindung aufgebaut, aber dann kein gültiges Zertifikat ausgetauscht. Seltsamerweise waren bei den üblichen TLS-Testern keine Fehler feststellbar.

Beim Chaostreff habe ich dann erfahren, dass Apple keine 8kB Zertifikate verträgt. (Da gibt es auch schon den einen oder anderen Blogeintrag zu). Und da ich als kleiner Paranoiker ein solches Zertifikat generiert hatte, schlug der Bug dann auch bei mir zu.

Jetzt werde ich also mal die Zertifikate gegen kleinere austauschen müssen. Allerdings wird bei StartSSL kein neues Zertifikat ausgestellt bevor das Alte abgelaufen ist. Somit werde ich dann wohl doch zu CACert wechseln. Somit wird demnächst wohl eine Warnmeldung auftauchen, dass das Zertifikat gewechselt wurde und es jetzt nicht mehr von einer vertrauenswürdigen Stelle ausgestellt ist. Aber generell solltet ihr, sofern noch nicht geschehen, die CACert Stammzertifikate mal bei euch im Browser installieren.

Server Neuinstallation

Mein Server läuft jetzt wieder einigermaßen rund auf Debian Stable. Vorher lief ich auf einem Ubuntu 12.04 LTS, was mir an der einen oder anderen Stelle aber nicht gefallen hat. Auch sind die Pakete in Ubuntu deutlich älter und für Dinge wie namensbasierte, verschlüsselte virtelle Hosts im Apache einfach nicht geeignet. Auch wollte ich das Setup für den Mailserver selber konfigureiren und nicht einfach die vorgegebenen Dovecot- und Postfix-Einstellungen übernehmen.
Und da der Mailserver jetzt ganz okay läuft, habe ich auch mal wieder das passende WordPress installiert. Ich werde wohl noch ein paar alte Beiträge von meinem alten Webspace aus der Datensicherung kratzen, aber erstmal läuft das hier wohl jetzt.