Blog & White

Second part of my DNS setup notes, this time about DNSSEC. The following notes assumes there is already a running instance of Bind 9 on a Debian Jessie system for an imaginary domain example.com, served by a name server named ns.example.com.

The version of Bind 9 (9.9.5) on Debian Jessie supports "inline signing" of the zones, meaning that the setup is much easier than in the tutorials mentioning dnssec-tools or opendnssec.

Again these notes are mostly based on the example from the ISC Knowledge Base.

Setting up a signed zone

If you have a delegated zone (like home.example.com from the first part), do the following for both example.com and home.example.com.

Generate the keys

On a machine with enough available entropy in /dev/random (such as a Raspberry Pi with its hardware random number generator ) run

dnssec-keygen example.com
dnssec-keygen -fk example.com

(you can add the -r /dev/urandom option to the command if you dare, if /dev/random is too slow. It can literaly take hours to generate those keys otherwise).

Transfer the keys to the server where Bind is running.

Configure Bind

Create a /etc/bind/keys directory where to put the keys. Ensure the .private files belong to root, are readable by the group bind and not by other users.

In named.conf.options add to the options block:

options {
        …
        dnssec-enable yes;
        dnssec-validation auto;
        dnssec-lookaside auto;
        …
};

Create in /var/cache/bind a symbolic link to /etc/bind/db.example.com.

In named.conf.local, in the zone "example.com" block, add

zone "example.com" {
				…
        #file "/etc/bind/db.example.com";
        file "/var/cache/bind/db.example.com";
        key-directory "/etc/bind/keys";
        auto-dnssec maintain;
        inline-signing yes;
};

Note that the db file must point to a file in /var/cache/bind, not in /etc/bind. This is because bind will create a db.example.com.signed file (among other related journal files), constructed from the path of the "file" entry in the zone declaration, and it will fail doing so if the file is in /etc/bind, because Bind would attempt to create the .signed file in this read-only directory.

Then reload the configuration with

rndc reconfig

Then check that the zone is signed with

rndc signing -list example.com

Linking the zones

Your registrar should provide a tool (most probably Web based) where to put DS records for your domain.

On the DNS server, generate a DS record with

dig @localhost dnskey example.com | /usr/sbin/dnssec-dsfromkey -f - example.com

Copy and paste these lines in the registrar's tool. After a little while, you should be able to query the DS record with

dig @localhost -t ds example.org

If you have a delegated zone such as home.example.com, generate a DS record for that zone with

dig @localhost dnskey home.example.com | /usr/sbin/dnssec-dsfromkey -f - home.example.com

and place these lines in db.example.com (i.e., the db file for the parent zone). Change the serial number of the zone in the same file and run

rndc reload

You should then be able to query the DS record with

dig @localhost -t ds home.example.org

You can use Verisign's DNS debugging tool to check that the signatures are valid and DNSViz to view the chain of signatures from the TLD DNS down to your DNS. This also helped me figure out that my zone delegation was incorrect and caused discrepancies between my primary DNS server and the secondary server.

Now that I have my own server, I can finally have my own DNS server and my own domain name for my home computer that has a (single) dynamic IP address.

The following notes assumes there is already a running instance of Bind 9 on a Debian Jessie system for an imaginary domain example.com, served by a name server named ns.example.com and you want to dynamically update the DNS records for home.example.com. This is largely based on the Debian tutorial on the subject, solving the problem that bind cannot modify files in /etc/bind.

On the server

Create a shared key that will allow to remotely update the dynamic zone:

dnssec-keygen -a HMAC-MD5 -b 128 -r /dev/urandom -n USER DDNS_UPDATE

This creates a pair of files (.key and .private) with names starting with Kddns_update.+157+. Look for the value of Key: entry in the .private file and put that value in a file named /etc/bind/ddns.key with the following content (surrounding it with double quotes):

key DDNS_UPDATE {
        algorithm HMAC-MD5.SIG-ALG.REG.INT;
        secret "THIS IS WHERE YOU PUT THE KEY";
};

You can then delete the two Kddns_update.+157+ files. Ensure that /etc/bind/ddns.key belongs to "root" and to the "bind" group, and is not readable by other users.

Then in named.conf.local, include the key file and declare a new zone:

include "/etc/bind/ddns.key";


zone "home.example.com" {
        type master;
        file "/var/cache/bind/db.home.example.com";
        allow-update { key DDNS_UPDATE; };
        journal "/var/cache/bind/db.home.example.com.jnl";
};

In /var/cache/bind create the file db.home.example.com by copying /etc/bind/db.empty and adapting it to your needs. For convinience, create a db.home.example.com symbolic link in /etc/bind pointing to /var/cache/bind/db.home.example.com.

In db.example.com (that is, the parent zone), add a NS entry to delegate the name home.example.com to the DNS server of the parent zone:

home.example.com NS ns.example.com

You can now reload the bind service to apply the configuration changes.

I also found examples of how to test the dynamic zone with nsupdate.

On the home computer

I decided to use ddclient 3.8.3 because it supports dynamic dns updates using the nsupdate tool. I backported that version of ddclient manually from a Debian Testing package; it's written in Perl and the backporting is trivial.

Copy /etc/bind/ddns.key from the server to /etc/ddns.key on the home computer (the one running ddclient), ensuring only root can read it. Then add the following to /etc/ddclient.conf (be careful with the commas, there is no comma at the end of the second last line):

protocol=nsupdate, \
zone=home.example.com, \
ttl=600, \
server=THE_IP_ADDRESS_OF_THE_DNS_SERVER, \
password=/etc/ddns.key \
home.example.com

You can then try out the new setup.

“biscuity malty… resinuous pine… citrus notes… mango”

Quite fruity, quite possibly mango. The rest is lost to me. Contains barley.

BrewDog Ltd., Fraserburgh, Scotland. 4.5% alcohol.

What is the minimum entropy for my home computer's password?

In recent (post-2007) Debian (and probably other) Linux distributions, the passwords are stored in /etc/shadow using the sha512crypt algorithm. According to Per Thorsheim, with 2012 hardware, a single Nvidia GTX 580 could make 11,400 attempts at brute-force cracking such a password. This means that a log₂ 11,400 = 13.5 bit password could be cracked in 1 second.

To have a password that would resist a year to such a brute-force attack, one must multiply the password complexity by 86,400×365 (seconds per year) i.e., add 24.5 bits to the password for a total of 38 bits.

But this password is guaranteed to be cracked in a year. To make the probability of cracking such a password much lower, let's say less than 0.01, one must increase the password's complexity by a hundred times i.e., add 6.7 bits. We now have a minimum of 44.7 bits.

If one does not want to change the password for the next 10 years (because one is lazy), one must again increase the complexity tenfold (that's another 3.3 bits for a total of 48 bits) and account for the increase in processing power in the coming years. Between 2002 and 2011, CPU and GPU computing power has been multiplied by 10 and 100 respectively i.e., +0.37 and +0.74 bits/year. That means that the password's complexity must be increased by 0.74 ×10 = 7.4 bits. We have now reached 55.4 bits.

Now we need to guess who are the password crackers. How many such GPU will they put together? Titan has 18,688 GPUs (add another 14.2 bits to stay ahead of it), and the (more affordable) machine that cracked LinkedIn leaked passwords had 25 GPUs (requiring to add only extra 4.6 bits).

Assuming the crackers have a 25-GPU setup and not a gigantic cluster, 60 bits should be perfectly safe. If they are a government agency with huge resources and your data is worth spending the entirety of that cluster's energy for 10 years, 70 bits is still enough.

The same article also mentions an Intel i7, 6-core CPU would make 1,800 attempts per second i.e., 10.8 bits. For a password that must resist for 10 years, that would mean 49 bits. Titan has 300,000 CPU cores (50,000 times more than the i7), so that makes an extra 15.6 bits for a total of 64.6 bits. The Tianhe-2 has 3,120,000 cores, adding 19 bits to the original 49 bits, leading to 68 bits total.

In summary, 70 bits is enough. If you are lazy and not paranoid, 60 bits are still enough. If you think the crackers will not use more than 32 i7 CPUs for a month to try and break your password (adding 2.4 + 21.3 bits to the original 10.2 bits), 48.5 bits are still enough.

Gargamel in now a famous stage magician in Paris. He has created two smurf-like creatures out of gray clay, Vexy and Hackus, and captured the Smurfette through a vortex, using almost all his dragon wand's power. He hopes to convince the Smurfette to revar him the secret formula Papa Smurf had used to turn her into a Smurf; his secret goal is to turn the grey creatures into Smurfs to harvest their essence. The Smurfette refuses, but finally accepts seeing her now-friend Vexy suffer when Gargamel refused to give her her daily dose of Smurf essence. Meanwhile, three Smurfs and Papa Smurf teleport to New York where they meet Patrick and his family. They all travel to Paris and eventually defeat Gargamel and save the Smurfette. Upon returning to the village, Vexy and Hackus are turned into Smurfs.