Microblog : A very long article Wikipedia article on the orientation of toilet paper [7 jun à 22:52] [R]

Mercredi, 27 avril 2016


Traduction: [ Google | Babelfish ]

Catégories : [ Informatique ]

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.

[ Posté le 27 avril 2016 à 19:21 | pas de commentaire | ]