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-signzonefrom 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:
- Create two new key pairs: key-signing key, and zone-signing key.
- Use both keys and
dnssec-signzoneto sign the zone.
- 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-signzonesorts 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
.czzone, 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
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+.keyfile: 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+.keycommand. The fingerprint displayed should match the one in the
On the positive side, there are
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?