Yenya's World

Wed, 11 Aug 2010

DNSSEC Tools Suck

So we have the root DNS zone signed now. Probably a good time to start thinking about deploying DNSSEC in our DNS zones as well. Now what the best practices are? And which tools are the best for the job? As far as I can tell, the situation is less then pleasant now:

dnssec-signzone from the BIND package is crap.
It is designed against the UNIX philosophy of doing one thing and doing it well. For example, it cannot sign a single record set. More rants below.
The HOWTOs do not match the best practices.
All the HOWTOs there are written along these lines:
  1. Create two new key pairs: key-signing key, and zone-signing key.
  2. Use both keys and dnssec-signzone to sign the zone.
  3. Profit!
But the whole purpose of separating KSK from ZSK (and having stronger KSK) is defeated by this approach: the purpose of having a separate KSK is that the private part of KSK can then be available only in a locked-up privilege domain (possibly stored on a hardware token or on a different box than the primary nameserver). ZSK, on the other hand, can then be used for auto-updating the expired signatures, etc. The DNSSEC best practices are outlined in RFC 4641.
The tools do not match the best practices.
With the current tools, it is simply not possible to have KSK on a different box, to sign only the DNSKEY RRSET there, copy the result (with a private part of a short-term ZSK) to the primary nameserver, and sign (and eventually re-sign) the rest of the zone using the ZSK there.
No tool can re-use the signatures from another source.
The problem is that dnssec-signzone sorts the zone file, removing any previous formating and comments. So the signed zone file is not suitable as a primary place where the modifications are done. But when we use the original unsigned zone file as the primary source, everything has to be re-signed each time the zone is modified. It does not matter much for small or low-profile zones, but e.g. for the .cz zone, CZ.NIC has apparently written their own scripts which can reuse the signatures from the old signed zone file.
No tools for key management
There is no suitable tool for having KSK encrypted with a passphrase. For ZSK rotation, it is not possible to determine which of the many zone-signing keys in the directory is the active one and which is the pre-published standby, etc.
Root zone KSK verification is awkward
IANA publishes only the fingerprint of the trust anchor. But it is not easy to verify whether the root KSK matches the signature in the trust anchor file. So far I have discovered only the following method:
  • Get the trust anchor XML file (and possibly verify its authenticity).
  • Get the root public KSK: 
    host -t DNSKEY . > K.+008+.key
    (the file name is important here).
  • Edit the K.+008+.key file: remove the ZSK (KSK is the key with flags 257), and convert it to the DNS key file format: 
    . IN DNSKEY 257 3 8 AwEAA...nulq QxA+Uk1ihz0=
  • Run the dnssec-dsfromkey -2 K.+008+.key command. The fingerprint displayed should match the one in the root-anchors.xml file.

On the positive side, there are Net::DNS::SEC and Net::DNS::ZoneFile::Fast CPAN packages for Perl. I have started to write my own key- and zone-management tool for DNSSEC using these packages. I will see whether the result is general enough to be worth publishing it for other people. Should this be the case, I would need a neat name for this tool. So far the script is named dstool which is rather lame. Any suggestions, my dear lazyweb?

Section: /computers (RSS feed) | Permanent link | 0 writebacks

0 replies for this story:

Reply to this story:

 
Name:
URL/Email: [http://... or mailto:you@wherever] (optional)
Title: (optional)
Comments:
Key image: key image (valid for an hour only)
Key value: (to verify you are not a bot)

About:

Yenya's World: Linux and beyond - Yenya's blog.

Links:

RSS feed

Jan "Yenya" Kasprzak

The main page of this blog

Categories:

Archive:

Blog roll:

alphabetically :-)