$Revision: 1.14 $
Whith the introduction of DNSSEC, zone maintainers will have to also take up the responsibility of maintaining the private and public key material that is used for signing the zones.
Since improper key management could cause verifying DNS clients not to accept one's DNS data, key management becomes an important operational aspects. The private key material needs to be properly protected in a DNSSEC environment and one has to take into account the dynamics of how pubic keys "travel" through the DNS.
This is the documentation for a set of tools with which a DNSSEC key maintenance system can be build. The key maintenance system can be used to build a "secure key store" and it has some knowledge about "key rollover techniques" relevant to DNSSEC.
Table of Contents
This documentation is under development. Just as the code this documentation came with is a development release. Please help us catch serious bugs and let us know if you have any suggestions for improvement.
Table of Contents
Zone Signing is the core of DNSSEC management. During the signing of a zone DNSSIG resource records are created for all the data in the zone file. Using these signatures and related public keys security aware DNS clients can verify the validity of DNS data. In addition to creating signatures the signing process introduces NSEC RRs that can be used to validate the non-existence of data.
BIND 9.3.0 contains a tool called dnssec-signzone. This tool signs the zone and introduces the NSEC RRs. To use this tool users have to create key pairs, keep track of these keys and ensure proper usage.
This software suite is intended to ease key management issues. Using this tool people maintaining signed zones do not have to maintain manual logs of which keys are in use.
The intention is that zone signing is "orthogonal" to the key maintenance. The maintkeydb command is used to maintain the keys for a given zone while the dnssigner program will sort out, based on the zone, which keys to use for signing, and which public keys to insert into the zone. The persons running the dnssigner command is not required to have knowledge of which keys are in use, they do not even need "physical" access to the private key material.
The maintkeydb tool offers some assistance to the key manager with maintaining consistency during the key rollovers.
The key management procedures that are implemented are based on early experience. See also the Internet Draft 'DNSSEC key operations' draft-kolkman-dnssec-operational-practices-01.txt which describes the key rollover described herein.
Table of Contents
maintkeydb is the tool designed to maintain keys used for DNSSEC operations. This chapter intends to provide you with a number of examples of the use of maintkeydb while performing certain key management tasks. ( Also see Appendix A, "Cookbook" if you think this chapter is a little too verbose. )
It is assumed that the software is installed on a machine on which the private key are stored. We will refer to as the signer box or shorter, the box. Once the box is configured you can start maintaining your keys. The program maintkeydb is your interface. It can be used in two different ways. With direct command line arguments or as an interactive shell.
Use perldoc maintkeydb to read the documentation that comes with the tool itself.
> maintkeydb create help Purpose: create new keys You can choose to generate a ksk, a zsk or both keys. If keys are first create for a zone then multiple zone signing keys are created, thereby bootstrapping the prerequisites for automatic rollovers using the rollovers command. The system will not create keys if it thereby might disable automatic rollover. Use "force" to force creation of keys. The usage is as follows: create ["force"] <"zsk"|"ksk"|"both"> <RSASHA1|DSA|RSA|RSAMD5> <size> <zone[[ zone]...]>
maintkeydb create will create one key signing key and two zone signing keys will be created. One ZKS set as "active" which means it is used for signing, and one set as "published" which means it is not used for signing zone data. This particular set of keys is created so that the prerequisites for a successful key rollover are met.
bash $ maintkeydb create both RSASHA1 1024 example.com Created 3 keys for example.com bash $ maintkeydb list example.com example.com RSASHA1 25379 ZSK published (0d00h00m) example.com RSASHA1 25589 ZSK active (0d00h00m) example.com RSASHA1 58140 KSK active (0d00h00m)
It could well be that you would like to have the zone signing key and the key signing key of different length. In that case you will have to specify either zsk or ksk instead of both in the line above.
Instead of using maintkeydb the command line you can also use it as a shell. Below is an example.
maintkeydb -i Command? >create Force creation? [skip|force] > skip Create a KSK, a ZSK or both? type > ksk Algorithm? algorithm > RSASHA1 Key Size? keysize > 2048 Enter one or more zone names zone(s) > example.net Created 1 key for example.net Command? >list active, inactive, rollover or published keys? state > allstates KSK or ZSK? type > both Enter one or more zone names zone(s) > all example.com RSASHA1 25379 ZSK published (0d00h01m) example.com RSASHA1 25589 ZSK active (0d00h01m) example.com RSASHA1 58140 KSK active (0d00h01m) example.net RSASHA1 10320 KSK active (0d00h00m) Command? >create zsk RSASHA1 1048 example.net Created 2 keys for example.net Command? >list allstates zsk Enter one or more zone names zone(s) > all example.com RSASHA1 25379 ZSK published (0d00h02m) example.com RSASHA1 25589 ZSK active (0d00h02m) example.net RSASHA1 08906 ZSK published (0d00h00m) example.net RSASHA1 17639 ZSK active (0d00h00m) Command? >exit bash $
There are two methods to delete keys. You can either delete keys by providing a zone name, algorithm and key id or you can, more crudely delete all keys for a specific zone at once. Use delete_id or delete_name respectively. Below are two examples of deleting keys with maintkeydb, one in "shell" mode one from the command line.
bash $ maintkeydb -i Command? >delete_id help Purpose: Delete keys by keyid Zone-Algorithm-KeyID uniquely defines a key. Use the list <zone> to identify the keys. In shell mode command-line completion [tab] will show you the available KeyIDs. delete_id <zone> <RSASHA1|DSA|RSA|RSAMD5> <keyID[[ keyID] ...]> Command? >delete_id Enter a zone name zone > example.net Algorithm? algorithm > RSASHA1 Enter one or more KeyIDs? keyID > [press TAB] 08906 10320 17639 keyID > 08906 Deleting: example.net RSASHA1 08906 ZSK published (10d21h02m) Command? >list example.net allstates both example.net example.net RSASHA1 10320 KSK active (10d21h03m) example.net RSASHA1 17639 ZSK active (10d21h03m) Command? >exit bash $
bash $ maintkeydb delete_name help Purpose: Delete keys by name To delete the KSK, the ZSK or just all keys for given algorithm and zones. Be careful you will not be asked for confirmation. Specfying at least one zone is mandatory. delete_name <"zsk"|"ksk"|"both"> <RSASHA1|DSA|RSA|RSAMD5> <zone[[ zone]...> bash $ maintkeydb delete_name both RSASHA1 example.net Deleting: example.net RSASHA1 10320 KSK active (10d21h05m) Deleting: example.net RSASHA1 17639 ZSK active (10d21h04m) bash $ maintkeydb list example.com RSASHA1 25379 ZSK published (10d21h07m) example.com RSASHA1 25589 ZSK active (10d21h07m) example.com RSASHA1 58140 KSK active (10d21h07m) bash $
Rolling the key pairs is an operation that needs to be done on a regular basis. During a key rollover one key pair gets replaced by another. During the rollover one has to take care of the propagation of the key information through the DNS. Please refer to I-D-dnsop-dnssec-operational-practices-01 for details of the key rollover scheme that has been implemented.
There are two types of rollovers to consider. That of zone signing keys, an operation that does not need 'external' interaction and can be done relatively frequently. The other type of rollover is the rollover of keys signing keys. During that type of rollover public key information needs to be "uploaded" to DNS parents or configured in verifiers. A key signing key rollover will typically occur less frequently than a zone signing key rollover.
In general the rollover happens in two stages, during the first stage the preparations are done. The new keys et has to propagate through the Internet. How fast that happens depends on how fast the changes are applied to your zone (Through the signing operation), how fast the zone is served by secondary servers and on the TTLs on the data previously in your zone. That data may still live in distant caches (see I-D-dnsop-dnssec-operational-practices-01 for the details).
The tools do not provide hooks to test the state of the DNS (yet). You have to verify that all keys propagated to the Internet and wait for 2 TTLs before you engage in the second stage.
One needs to interact with "external" parties when rolling Key Signing Keys. During the first stage of the rollover a new Key Signing Key is introduced and the "old" key is marked as being in "rollover" stage.
bash $ maintkeydb list example.com example.com RSASHA1 25379 ZSK published (11d00h03m) example.com RSASHA1 25589 ZSK active (11d00h03m) example.com RSASHA1 58140 KSK active (11d00h03m) bash $ maintkeydb rollover ksk-stage1 RSASHA1 example.com bash $ maintkeydb list example.com example.com RSASHA1 25379 ZSK published (11d00h04m) example.com RSASHA1 25589 ZSK active (11d00h04m) example.com RSASHA1 36252 KSK active (0d00h00m) example.com RSASHA1 58140 KSK active (11d00h04m) (R)
The key marked as being in rollover will be deleted during stage2 of the rollover.
What you have to do now is make sure that your parent (the .com zone in this example creates a new DS record to point to your new key signing key. To find out which keys you will have to send to your parent you use the maintkeydb parent data command.
bash $ maintkeydb parentdata key example.com example.com. 0 IN DNSKEY 257 3 5 ( AQPiQ9Mlv9qqsqxwrENJY/EP1vhRPedQzlX5 8p80OKKIpLUNU4dko+9nz3yyJ2YP/V76yAZC SWwvdoXfWaTSB5lvO4+EzmLyCUu8ZizlD3jK AG3QYMoFyfr1AajteQ5kdyKoCXawRLgVSgdc J7BT/xzPHKlKgaJ96601otwKM1E8ML6HboTP jw+Dx0YVYhU8F/Wh8Bf1vbI8drgnX0yxi9+V kMx+FtvNO6i1MU2GVZp7j5CbACOhoSdK22U4 TpWUvG+IvulhZ6S6TjZFkwpq0xM0NecvE7Yn WimUwgmth2HJTZJCzbOWRMIHz3XPX0MCMVww +efOWnPFVlEy+V8vfunl ) ; Key ID = 36252 bash $
If your parent's registrar only accepts "DS" RRs you can alternatively
ds instead of
bash $ maintkeydb parentdata ds example.com example.com. 0 IN DS 36252 5 1 f2fb1958f15832749ad25f5e9707abcb933a8162 bash $
If you want to verify what appears in your zone file you can issue the maintkeydb showkeys command this will output the key set as it will appear in your zone file.
bash $ maintkeydb showkeys example.com ;;;;;; DNSKEY RRs for example.com ;;;;;;;;; example.com. 0 IN DNSKEY 256 3 5 ( AQOz8oz5sm5CCu4gCZBCI0URL319aAkrAGU6 rPYqNq8e3MZ5AaE3NAPwYsc7RX60U9xLNwtj qdnR0MjbilD1lXVAACdu5fm/B2xOhdx+8Q1a +SFKvM9ndQeARwWsE3NSIQ2rANFTNkoT+tkg 6S6QSzdmpvh1ESgHUd91sP1M5yxsUw== ) ; Key ID = 25379 ZSK example.com. 0 IN DNSKEY 256 3 5 ( AQO+fa+ITw4/aY5B0L7mRaCkeFMW0YFcodun rYPhHnmu+2duUP/Z29mUW/MBEuaBCoXpzC7Z ekaTpFx5t8MZ/2MsqtjhRifbE309Zgbo2fLC vAFB7AAVpvsZdscTbQ/wNxS7m93q4WtyDDyh IyV/KGvQ7eGRfd4GQVN8dhsgBpty5Q== ) ; Key ID = 25589 ZSK example.com. 0 IN DNSKEY 257 3 5 ( AQPiQ9Mlv9qqsqxwrENJY/EP1vhRPedQzlX5 8p80OKKIpLUNU4dko+9nz3yyJ2YP/V76yAZC SWwvdoXfWaTSB5lvO4+EzmLyCUu8ZizlD3jK AG3QYMoFyfr1AajteQ5kdyKoCXawRLgVSgdc J7BT/xzPHKlKgaJ96601otwKM1E8ML6HboTP jw+Dx0YVYhU8F/Wh8Bf1vbI8drgnX0yxi9+V kMx+FtvNO6i1MU2GVZp7j5CbACOhoSdK22U4 TpWUvG+IvulhZ6S6TjZFkwpq0xM0NecvE7Yn WimUwgmth2HJTZJCzbOWRMIHz3XPX0MCMVww +efOWnPFVlEy+V8vfunl ) ; Key ID = 36252 KSK (upload to parent) example.com. 0 IN DNSKEY 257 3 5 ( AQPZOKdG8V8mf63picc28uNeAY5nwknkMkNT oEbQsALnAC4tlMxgb7gs2mcL6z05qTLUIj9F tmRO9tpfy7RTaM2XwHx2n9opLhDJYEbD4pYD pGe+ktXKmLaSkjgIF9RvQ44sHpIIteqqakGr T1Lavtj9IBl8V/Mvam55DLXFjtjV5w== ) ; Key ID = 58140 KSK (to be depricated) bash $
or, if you want to see the KSKs in your keyset only use the
ds option, that will only print the key signing keys, as a bonus
the DS RRs will be printed.
bash $ maintkeydb showkeys ds example.com ;;;;;; DNSKEY RRs for example.com ;;;;;;;;; example.com. 0 IN DNSKEY 257 3 5 ( AQPiQ9Mlv9qqsqxwrENJY/EP1vhRPedQzlX5 8p80OKKIpLUNU4dko+9nz3yyJ2YP/V76yAZC SWwvdoXfWaTSB5lvO4+EzmLyCUu8ZizlD3jK AG3QYMoFyfr1AajteQ5kdyKoCXawRLgVSgdc J7BT/xzPHKlKgaJ96601otwKM1E8ML6HboTP jw+Dx0YVYhU8F/Wh8Bf1vbI8drgnX0yxi9+V kMx+FtvNO6i1MU2GVZp7j5CbACOhoSdK22U4 TpWUvG+IvulhZ6S6TjZFkwpq0xM0NecvE7Yn WimUwgmth2HJTZJCzbOWRMIHz3XPX0MCMVww +efOWnPFVlEy+V8vfunl ) ; Key ID = 36252 KSK (upload to parent) example.com. 0 IN DNSKEY 257 3 5 ( AQPZOKdG8V8mf63picc28uNeAY5nwknkMkNT oEbQsALnAC4tlMxgb7gs2mcL6z05qTLUIj9F tmRO9tpfy7RTaM2XwHx2n9opLhDJYEbD4pYD pGe+ktXKmLaSkjgIF9RvQ44sHpIIteqqakGr T1Lavtj9IBl8V/Mvam55DLXFjtjV5w== ) ; Key ID = 58140 KSK (to be depricated) ;;;;;; DS RRs for example.com ;;;;;;;;; example.com. 0 IN DS 36252 5 1 f2fb1958f15832749ad25f5e9707abcb933a8162 ; The next DS RR is an old one, it is to disappear example.com. 0 IN DS 58140 5 1 877d2eeba0e626066bd8ee5e5099ab9c7e1e387d bash $
Note the comments that indicate which keys are to be sent to the parent.
You will now have to wait until your parent has published the "new" DS RR and for the "old" DS RR to expire from all the caches, that live somewhere on the Internet and are not under your control. It will take at least the TTL value of the "old" DS RR as published by your parent for that to happen. You may want to play safe and wait for the signature over the "old" DS to be expired before pulling the DNSKEY it points to. Pulling the DNSKEY is done by "stage2" of the rollover.
bash $ maintkeydb rollover ksk-stage2 RSASHA1 example.com bash $ maintkeydb list example.com example.com RSASHA1 25379 ZSK published (11d18h16m) example.com RSASHA1 25589 ZSK active (11d18h16m) example.com RSASHA1 36252 KSK active (0d17h13m)
You can verify that the key previously marked to be in "rollover" has now been removed.
The prerequisite for a zone signing key rollover is that there are two keys present, one is set to active and is used for signing, the other is only published i.e. available in the DNS, but is not used for signing. If you have used the "create" function with the default settings the two keys should have been created.
Again you have to take into account that it takes a while before data published in the DNS has reached all the clients. So do not roll to fast. The timing mostly depends on your TTL settings.
We perform a stage one rollover using the interactive mode:
bash $ maintkeydb list example.com example.com RSASHA1 25379 ZSK published (11d20h03m) example.com RSASHA1 25589 ZSK active (11d20h03m) example.com RSASHA1 36252 KSK active (0d20h00m)
Command? >rollover Enter rollover stage? rollover stage > zsk-stage1 Algorithm? algorithm > RSASHA1 Enter one or more zone names zone(s) > example.com Command? >list active, inactive, rollover or published keys? state > allstates KSK or ZSK? type > zsk Enter one or more zone names zone(s) > example.com example.com RSASHA1 25379 ZSK active (0d00h00m) example.com RSASHA1 25589 ZSK published (0d00h00m) (R) Command? > exit bash $
You can tell that the key with key ID 25589, the key that was previously active is set to "published" and has its rollover attribute set (the "(R)" behind the at the end). There is a newly created key with ID 25379 that is set to active. The times are both "reset" to 0 as these indicate the time since the last state change and both keys had a state change.
In the stage2 key rollover the published key with the rollover key will be deleted and a new key will be published that is ready for introduction as a signing key in the future. We demonstrate the stage two rollover in the command line mode.
bash $ maintkeydb rollover zsk-stage1 RSASHA1 example.com There is a key marked as being rolled You probably want to run zsk-stage2 for example.com (RSASHA1) bash $ echo $? 6 bash $
Oops.. typo... you see the tool provides a warning and returns a non-zero return code.
bash $ maintkeydb rollover zsk-stage2 RSASHA1 example.com bash $ echo $? 0 bash $ maintkeydb list example.com example.com RSASHA1 25379 ZSK active (0d00h07m) example.com RSASHA1 36252 KSK active (0d21h01m) example.com RSASHA1 61760 ZSK published (0d00h00m)
The dnssigner is the application that uses the key store to sign zones. The intention is that the "user" is not aware of which keys are currently being marked as "active", "passive" or in "rollover" but just signs the zone. During the signing operation the appropriate set of public keys will be added and the zone will be signed with the appropriate private keys.
The dnssigner command takes the following form:
dnssigner -h dnssigner -V General Flags -h print this help message and exit -V print version information and exit -v increase verbosity Client zonefile name of the zonefile. -o <origin> origin of the zone. If not supplied the name of the zone will be used as origin. -t print statistics of the signing process to stderr. -s YYYYMMDDHHMMSS|+offset: SIG start time - absolute|offset (now) -e YYYYMMDDHHMMSS|+offset|"now"+offset]: SIG end time - absolute|from start|from now (now + 30 days)
The arguments are similar BIND's dnssec-signzone except that key information is not needed.
The same functionality can be provided through a "SOAP" based zone signer server-client application. The client provides the zones and arguments while the server does all the work, all communication is over a SOAP channel. Refer to Section B.4, “ Configuring the SOAP based zone signer daemon ” for how to configure the daemon.
The client has exactly the same arguments as dnssigner but needs the address and port number of the server.
Usage: dnssigner_client -H <host> -P <port> [-o <ORIGIN>] [-s <STARTDATE>] [-e <ENDDATE>] <ZONEFILE> dnssigner_client -H <host> -P <port> -o <ORIGIN> (Zone file is fed through STDIN) dnssigner_client -? dnssigner_client takes (either from STDIN or from given file name) an unsigned DNS zone file, passes it through DNSSEC Signer Appliance and puts the signed zone file to STDOUT. Options: -? or -h Help. This message. -H host Host on which the dnssigner_daemon process runs -P port Port on which the dnssigner_daemon process runs -o ORIGIN Origin. if file is supplied it is optional and file name is taken as the origin. -s STARTDATE Start date -e ENDDATE End date ZONEFILE DNS zone file
Here we describe the steps to take when maintaining a zone.
bash $ maintkeydb create KSK RSASHA1 2048 example.net Created 1 key for example.net bash $ maintkeydb create ZSK RSASHA1 1024 example.net Created 2 keys for example.net bash $
Use the signer to sign your zone and publish the signed zone in the DNS.
bash $ dnssigner example.com Output written to :example.com.signed
After some time (say a few months) roll your zone signing keys.
bash $ maintkeydb rollover zsk-stage1 RSASHA1 example.net
Use the signer to sign your zone and publish the signed zone in the DNS. Wait until the change has been picked up by all your secondary servers and then wait at least the the maximum TTL value over all the records in your zone, then proceed with stage2.
bash $ maintkeydb rollover zsk-stage2 RSASHA1 example.net
Use the signer to sign your zone and publish the signed zone in the DNS.
Once ever so often (say once or twice per year) roll your key-signing keys
bash $ maintkeydb rollover ksk-stage1 RSASHA1 example.net
Use the signer to sign your zone and publish the signed zone in the DNS. Remember the TTL on the DS record currently at your parent. (dig example.net DS) and upload the new key that you obtain from the database with:
example.net. 0 IN DNSKEY 257 3 5 ( AQOv4Vvdv2K6zYhuc20+Kd0r9DbwEZamqig8 hthWSd02UF9MjWs2KRyYYGmMPfQktIwe6hyD gxcvWKEvMKn1swJWRT/jWhU6VA4vTW8a8h60 E5p8und0vp3+67kz2cuZpzEaZlj4boj42kmX SSHmCsS2BcmcwWPsEvEg3ikQFFT1VrCGIUl8 pUlJJLE+rczNND+9ab3eg4BzB1DTbRzHwkBj +giX3KezJ92SVjK0kbm8BDj/QlkyaaxuJcjG CjbJynIDL85ywdi66YYpGrELDuvyiDQ++os3 FfPslydIfZ6RDQMU1hrXPb/wJOwopIfxsR4/ Eqz5djr1cCHfehpLYTRx ) ; Key ID = 2526 example.net. 0 IN DS 2526 5 1 5aa9bff246e645776ab9cc3de130978df82e6090
Wait until your parent has published the new DS in all its authoritative servers and then at least another TTL of the previous DS (you noted that above). Only then perform stage2 of the KSK rollover:
bash $ maintkeydb rollover ksk-stage2 RSASHA1 example.net
Use the signer to sign your zone and publish the signed zone in the DNS and the rollover is done.
bash $ dnssigner example.com Output written to :example.com.signed
Note that the command issued is exactly the same, even after the rollover of the keys. The whole issue of key maintenance has been seperated from the signing of the zone.
Table of Contents
We provide the a perl
implements a "keystore". And a perl
implements the interactions between zonefiles and the keystore.
The maintkeydb application implements the user
interface using the first library while
dnssigner is the user interface for the
second.These software components can be integrated in the
provisioning chain but it is possible, and preferred, to use these
components to build a key store/signer application server.
The libraries can be used to build additional key management applications.
If the application server is properly set up getting access to the private keys will be non-trivial for users that do not have physical access to the machine.
Using ssh magic as in Figure B.1, “ssh configuration”, access to the key store/signer application can be provided through a dedicated interactive shell. That shell can be used to perform key pair creation, rollovers and other key management tasks. Users of the shell do not have access to the private key material.
Figure B.1. ssh configuration
Example content of ~/.ssh/authorized_keys2 consult the ssh documentation for details. command="/usr/local/bin/maintkeydb -i",no-port-forwarding,\ no-X11-forwarding,no-agent-forwarding ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAA...zrPyXc
Zones can be signed through a SOAP based client/server application. The zone signer uses the information stored in the key store to sort out which zones use which keys.
The key store/signer application server can be build using a out of the box components. A commodity PC with Linux and FreeBSD installed can be used. Some effort should be put in securing the box. We'll give some suggestions later.
These are the instruction for setting up the system. If you are setting up a key store/signer application server these instructions are relevant. See below for how to set up a zone signing client.
We assume that all installations are done in
/usr/local your mileage may vary if you try
to install the software elsewhere.
First you have to make sure you have installed BIND 9.3.0 or
more recent. It is important that during the installation you
have configured the package with the
--with-openssl configuration otherwise DNSSEC functionality
will not be available. For example:
cd bind9source-dir/ ./configure --with-openssl=/usr/local --prefix=/usr/local make
On the key store/signer application server you will need to install a recent perl5 and you will have to use CPAN to install a number of perl dependencies.
We have made a "bundle" available together that will allow for "easy" installations of the dependencies. Download the bundle's tar ball. And perform the following commands.
If you would like to install the perl dependencies manually than you can get a listing of them by unpacking the bundle and issuing the command perldoc KeystoreSignerPre.
There are at least two non-perl libraries that you have to have installed for all these modules to be installed succesfully. You will need openssl that is used by the perl crypto libraries Since there is some XML library dependency you will have to have the expat libraries installed on your system. These are available on sourceforge.
> tar -xvzf Bundle-Private-KeystoreSignerPre-0.001_1.tar.gz > cd Bundle-Private-KeystoreSignerPre-0.001_1 > perl Makefile.PL > sudo make install > sudo perl -MCPAN -e 'install Bundle::Private::KeystoreSignerPre'
Just enter the defaults for any questions asked during the installation process.
During the installation process you may see warnings like:
The most recent version "2.07" of the module "File::Copy" comes with the current version of perl (5.8.4). (...) Bundle summary: The following items in bundle Bundle::Private::KeystoreSignerPre had installation problems: File::Basename File::Copy File::Basename
it is safe to ignore these if you have a recent version of perl.
Once you have the prerequisite bundles installed you can start installing Net::DNS::SEC::Maint::Key and Net::DNS::SEC::Maint::Zone. You will need to install the packages in the above order. What follows is an example install session. Except for the version numbers, which may be different, you can just cut and paste these commands.
> tar -xvzf Net-DNS-SEC-Maint-Key-0.010_1.tar.gz > cd Net-DNS-SEC-Maint-Key-0.010_1 > perl Makefile.PL PREFIX=/usr/local > make > make test > sudo make install
> tar -xvzf Net-DNS-SEC-Maint-Zone-0.010_2.tar.gz > cd Net-DNS-SEC-Maint-Zone-0.010_2 > perl Makefile.PL PREFIX=/usr/local > make > make test > sudo make install
You should not get complaints about missing dependencies when you run perl Makefile.PL. During make test a number of tests are run. They will surely fail if dnssec-keygen and or openssl are not in your path.
Since the zone signer client has fewer dependencies the zone signer client script can be installed as a separate package. This package only depends on IO::Handle, File::Basename, Getopt::Std and SOAP::Transport::HTTP .
If you are uncertain the following command should get you all set:
perl -MCPAN -e 'install qw(IO::Handle File::Basename SOAP::Transport::HTTP);'.
Note that Getopt::Std is excluded. It comes with recent perl versions.
The installation package can be created from the Net-DNS-SEC-Maint-Zone distribution by running the create-client-dist.sh command.
> tar -xvzf Net-DNS-SEC-Maint-Zone-0.010_2.tar.gz > cd Net-DNS-SEC-Maint-Zone-0.010_2 > ./create-client-dist.sh
This will create a tar ball named
number probably differs). Copy this file to the appropriate machine and install.
> tar -xvzf Net-DNS-SEC-Maint-ZoneSigner-0.00_01.tar.gz > cd Net-DNS-SEC-Maint-ZoneSigner-0.00_01 > perl Makefile.PL PREFIX=/usr/local > make > make test > sudo make install
In order for the tools to work you will have to set up a couple of directories in which the private key material will be kept.
All users of the key store will need to be member of a specific
group we use the group
dnssecmt as the example
throughout this document. Make sure you edited
/etc/group to include the uid's you want to
allow access to private key material.
Create the needed directories and set the appropriate permissions by issuing the following commands.
mkdir /usr/local/var/dnssec_maint/ mkdir /usr/local/var/dnssec_maint/DNS_KEY_DB mkdir /usr/local/var/dnssec_maint/log mkdir /usr/local/var/dnssec_maint/tmp chmod -R o-rwx /usr/local/var/dnssec_maint chgrp -R dnssecmt /usr/local/var/dnssec_maint chmod -R g+rwX /usr/local/var/dnssec_maint
Once you have installed the software you have to configure your key store/signer. Both the key store and and the signer depend on the same configuration settings.
The Net::DNS::SEC::Maint::Key package came with dnssecmaint-config. You can use this program to install a configuration file. At a later stage you can use this program to modify your configuration.
dnssecmaint-config is called without
arguments. It will ask for a few configuration settings. In
most cases the defaults make sense. What follows is a example
session. The program must be run with write permissions for the
directory where you want to store the configuration file
(default location for this file will be
This is a program to write Net::DNS::SEC::Maint configuration files. It is typically used at install time or to create alternative configurations. Type 'exit' to leave the program. ---- conffile specifies where the configuration file can be found conffile is set to /usr/local/etc/dnssecmaint.conf Enter value for conffile>/usr/local/etc/dnssecmaint.conf ---- dns_key_db Path to the directory in which the key database is kept dns_key_db is set to /usr/local/var/dnssec_maint/DNS_Key_DB Enter value for dns_key_db>/usr/local/var/dnssec_maint/DNS_Key_DB ---- dnssec_keygen full path to BIND's dnssec-keygen command with optional arguments This vallue is currently set using the DNSSECMAINT_DNSSEC_KEYGEN dnssec_keygen is set to /usr/local/sbin/dnssec-keygen -r /dev/urandom Enter value for dnssec_keygen>/usr/local/sbin/dnssec-keygen -r /dev/urandom ---- dnssec_signzone full path to BIND's dnssec-signzone command with optional argume nts This vallue is currently set using the DNSSECMAINT_DNSSEC_SIGNZONE dnssec_signzone is set to /usr/local/sbin/dnssec-signzone -r /dev/urandom Enter value for dnssec_signzone>/usr/local/sbin/dnssec-signzone -r /dev/urandom ---- dsakeysizekey Default size for DSA Key Signing Keys dsakeysizekey is set to 1024 Enter value for dsakeysizekey>1024 ---- dsakeysizezone Default size for DSA Zone Signing Keys dsakeysizezone is set to 512 Enter value for dsakeysizezone>512 ---- logdir specifies the directory under logfiles are stored logdir is set to /usr/local/var/dnssec_maint/log Enter value for logdir>/usr/local/var/dnssec_maint/log ---- maintgroup Name of group that has R/W access to the dnssecmt maintgroup is set to dnssecmt Enter value for maintgroup>dnssecmt ---- rsakeysizekey Default size for RSA Key Signing Keys rsakeysizekey is set to 2048 Enter value for rsakeysizekey>2048 ---- rsakeysizezone Default size for RSA Zone Signing Keys rsakeysizezone is set to 768 Enter value for rsakeysizezone>768 ---- tmpdir Path to the directory in which temporary files are stored tmpdir is set to /tmp/ Enter value for tmpdir>/tmp/ Save configuration file to:/usr/local/etc/dnssecmaint.conf? (yes|no)>yes To use this configuration file you have to set DNSSECMAINT_CONFFILE=/usr/local/e tc/dnssecmaint.conf
The last line is particularly important. You will have to set the
DNSSECMAINT_CONFFILE to point to the relevant configuration file. You are best off if you do this for all users of the system.
On a related note. Most configuration parameters can be overwritten
by environment variables. This is essentially what the
dnssecmaint-config does internally. At
startup it tries to establish the path to BIND's
dnssec-keygen program and then sets
DNSSECMAINT_DNSSEC_KEYGEN. When the
dnssecmaint-config asks for the path for
dnssec-keygen you see a warning that the
default presented is read from the
DNSSECMAINT_DNSSEC_KEYGEN environment varialle.
Finally a warning. The system defaults to the use of
/dev/urandom as the random number generator. The
reason for doing so is that on a server without mouse and/or keyboard
the ammount of entropy gathered will not be enough to keep
/dev/urandom are pseudo random and not the best choice for key generation. Also see truly_random
We provide dnssigner for signing zones while having direct access to the filesystem on which the private keys live. This is often not the model under which the system is operated. Therefore we also provide an dnssigner_daemon and dnssigner_client application that communicate to each other over a "SOAP" based connection (see Figure B.2, “Architecture outline” and Section B.2.3, “Installing the zone signer client”).
You should start the daemon at system initialization. Start with two parameters the IP address and the port the daemon should start on.
Whenever you run dnssigner_daemon you will have to use the same IP address (or hostame) and portnumber.
 Do not hesitate to contact the developer if you run into problems
 Other errors than these are an indication that
things go wrong. During the tests of this bundle we constantly ran
into a problem with one of the more esotheric dependencies. During
the install of the libwww-perl package a few of the
t/robottests. After digging around for some time
we found that
/etc/hosts contained the wrong IP
address mapping for our hostname.
The system has been designed to be used as a frontend to BIND's dnssec-keygen and dnssec-signzone. Any person with shell access and appropriate permissions will have access to the private key material. The maintkeydb tool will obfuscate the private key material and if maintkeydb is used as a "user shell" than users will not be able to see the private key material.
The key material is stored in the directory configured in the
configuration file under
dns_key_db this directory
For each zone for which keys are maintained there is a sub
directory with the name of that zone. In these zones there is on
Expired_keys. This is where
keys are moved to when deleted. So in case of accidental
deletion somebody with physical access can still get to the
private key material.
In addition to the
directory the zone specific directories contain files called
The files with the extension
private contain the public and the private
key as generated by dnssec-keygen the
file with the extension
"attribute" information needed to operated the key store, while the
file with extension
adm contains some
administration and audit information.
You should replicate the database directory on a regular basis. Either by using a mirrored disk or by making regular backups on tape, floppy or optical media. Note that the backup media contain private key material and must thus be protected against disclosure or theft.
One of the methods to protect the private key material is to store it on an encrypting file system (for example CFS). When using a encrypting filesystem backups or replications can be made from the encrypted private keys and the private keys are better protected against physical theft.
The only thing we provide is the software to create the key store and the dnssigner that interacts with it. It is your own responsibility to create an application server that suits your security needs. Below we provide some hints on what sort of solutions you can apply to make your server more secure. The assumption is that dnssigning has to be done in an operational environment and on a regular basis. "Sneakernet" is not an option.
The system defaults into using
choice was made to prevent the system from blocking while waiting for
entropy to be gathered from a not-present keyboard. We suggest to use
hardware random number generators such as the ones available on
USB devices. See truly_random for details.
Use an encrypted file system to store the private keys (see Appendix C, Where do your private keys live)
The root user has access to the private key material
Only allow root access from "the console".
Make sure there are several firewalls between the application and the Internet.
Connect the key store/signer application server to a "management machine" through a cross cable.
Use IPtables to only allow an SSH connection and a connection over the SOAP port from the management machine.
Only allow the "keymaintainer" to log in via ssh, make the maintkeydb program the default shell for that user.
Paul Wouters, Miek Gieben and his colleagues at NLnet Labs for testing early beta's of this work and for giving feedback. Timothy Mc Ginnis and Emma Bretheric for reviewing the documentation.
[truly_random] Copyright © 2002 OpenFortress. How To Generate Truly Random Bits. http://openfortress.org/cryptodoc/random/ Link verified: April 2005 .
[dnssec-operational-practices] Copyright © 2005 ISOC. DNSSEC Operational Practices. March 2005. ftp://ftp.ripe.net/internet-drafts/draft-ietf-dnsop-dnssec-operational-practices-03.txt Link verified: April 2005 .
[rfc1034] Domain names - concepts and facilities. 1 November 1987. http://www.ietf.org/rfc/rfc1034.txt
[rfc1035] Domain names - implementation and specification. , , 1 November 1987. http://www.ietf.org/rfc/rfc1035.txt
[rfc4033] DNS Security Introduction and Requirements . March 2005 . http://www.ietf.org/rfc/rfc4033.txt
[rfc4034] Domain names - implementation and specification . March 2005 . http://www.ietf.org/rfc/rfc4034.txt
[rfc4035] Protocol Modifications for the DNS Security Extensions . March 2005 . http://www.ietf.org/rfc/rfc4035.txt