Zone signing with OpenDNSSEC - part 1

1. Initialize the Software "Hardware Security Module"

    Start by becoming root for this session (or use sudo when required)

    $ sudo -s
    #

	# mkdir /var/lib/softhsm/tokens
    # softhsm2-util --init-token --slot 0 --label OpenDNSSEC

    (use '1234' for both questions below): 

	=== SO PIN (4-255 characters) ===
	Please enter SO PIN: ****
	Please reenter SO PIN: ****
	=== User PIN (4-255 characters) ===
	Please enter user PIN: ****
	Please reenter user PIN: ****

    The token has been initialized.

    # softhsm2-util --show-slots

2. Modify /etc/opendnssec/conf.xml to use the SoftHSM

Find the section

<!--
          <Repository name="SoftHSM">
                        <Module>/usr/lib/softhsm/libsofthsm.so</Module>
                        <TokenLabel>OpenDNSSEC</TokenLabel>
                        <PIN>1234</PIN>
                        <SkipPublicKey/>
                </Repository>
-->

And remove the comments (<!-- and -->) before and after.

    Also, set the correct path for the libsofthsm.so in the conf.xml:

    Change:

<Module>/usr/lib/softhsm/libsofthsm.so</Module>

to

<Module>/usr/lib/softhsm/libsofthsm2.so</Module>

In the end you should have:

          <Repository name="SoftHSM">
                        <Module>/usr/lib/softhsm/libsofthsm2.so</Module>
                        <TokenLabel>OpenDNSSEC</TokenLabel>
                        <PIN>1234</PIN>
                        <SkipPublicKey/>
                </Repository>

2. Change the default Policy to use NSEC instead of NSEC3:

    Edit /etc/opendnssec/kasp.xml

    Find this section, and remove all the lines from <NSEC3> ... </NSEC3>

    <NSEC3>
        <!-- <OptOut/> -->
        <Resalt>P100D</Resalt>
        <Hash>
            <Algorithm>1</Algorithm>
            <Iterations>5</Iterations>
            <Salt length="8"/>
        </Hash>
    </NSEC3>

    ... and replace them with this single line:

    <NSEC/>

    Save & exit.



3. Initialise the database

# ods-enforcer-db-setup
*WARNING* This will erase all data in the database; are you sure? [y/N] y
Database setup successfully.

# chmod 755 /var/lib/opendnssec
# mkdir /var/lib/opendnssec/enforcer
# mkdir /var/lib/opendnssec/signer
# chown opendnssec:opendnssec /var/lib/opendnssec/enforcer
# chown opendnssec:opendnssec /var/lib/opendnssec/signer

Restart the enforcer:


Import default policy (from /etc/opendnssec/conf.xml)

# ods-enforcer policy import
Created policy default successfully
Created policy lab successfully
policy import completed in 0 seconds.


4. Install a copy of the unsigned zone for OpenDNSSEC to sign

    Let's use the backup of our master zone and make it available to
	opendnssec (that file should NOT have any '$include' statements).

    # cd /etc/bind/master
    # cp mytld.backup /var/lib/opendnssec/unsigned/mytld

    Increment the serial in the mytld file, so that it's up-to-date
    (YYYYMMDDXY).

5. Add the zone to OpenDNSSEC's database:

    # ods-enforcer zone add --zone mytld

	input is set to /var/lib/opendnssec/unsigned/mytld.
	output is set to /var/lib/opendnssec/signed/mytld.
	Zone mytld added successfully
	zone add completed in 0 seconds.

6. Restart the signer

	# service opendnssec-signer restart

7. Check that the zone is signed

    # ls -l /var/lib/opendnssec/signed/

    -rw-r--r--  1 root  wheel  2621 Feb 19 09:10 mytld

    Take a look at the contents of the zone - note the key ids for
    the KSK and ZSK.

    If for some reason, you don't see a file in this directory
    (/usr/local/var/opendnssec/signed/), then force the signer to sign:

    # ods-signer sign mytld

9. Moment of reflection

    Ok, so now the zone is signed with OpenDNSSEC - do notice that the
    zone was signed, but you didn't issue any commands to generate keys.

    List the keys currently managed by OpenDNSSEC:

    # ods-enforcer key list

Keys:
Zone:                           Keytype:      State:    Date of next transition:
mytld                           KSK           publish   2014-03-21 04:25:30
mytld                           ZSK           active    2014-03-21 04:32:30

    Notice that two keys have just been created by OpenDNSSEC, on the fly.

    But BIND is still loading the zone that was signed earlier (either
    manually or using the inline signer) - can we just modify the named.conf
    definition and point to the signed zone instead ?

    Which KSK is currently being used ? And which DS record is published
    in the parent zone ?

    Would the resolvers be able to verify the signatures on the zone
    signed with OpenDNSSEC ?  Why not ? What would you have to do for
    it to work (there are several possible answers)

    If you don't care about the validation problem, then you can proceed
    with the rest of this lab.

10. Tell BIND to load the new zone

    Modify /etc/bind/named.conf.local, and change the zone definition for "mytld"
    so it looks like this (REMOVE auto-dnssec, etc...)

zone "mytld" {
    file "/var/lib/opendnssec/signed/mytld";  // <--- Change path
    type master;
    key-directory "/etc/bind/keys";   // <--- Remove if there
    auto-dnssec maintain;               // <--- Remove if there
    inline-signing yes;                 // <--- Remove if there
};

    Now, BIND is back to being a "passive" nameserver that doesn't sign
    the zone - it just serves the zone signed by OpenDNSSEC.

    Restart named:

    # service named restart

    Check the logs in /etc/namedb/log/general to make sure that the zone
    is loading correctly.

    Now, validation will probably fail for those trying to look up data
    in your zone. Wait a few minutes, and try to lookup a record in your
    zone:

    # dig @127.0.0.1 www.mytld +dnssec

    What do you notice ?

11. OpenDNSSEC reload BIND

    Even better, you can have OpenDNSSEC tell BIND to reload the zone when
    it has been signed - like this, no need to manually reload.

    To do this, modify /etc/opendnssec/conf.xml

    Find the lines:

<!--
                <NotifyCommand>/usr/sbin/rndc reload %zone</NotifyCommand>
-->

    ... remove the comments (the lines '<!--' and '-->') before and after.

    Save the file, and restart OpenDNSSEC:

    # ods-control stop
    ...
    # ods-control start


12. Export the DS, ready to upload:

    Verify the state of the KSK at this stage:

    # ods-enforcer key list

    Note the state that the KSK is in.

    If it is still in publish state (see
    https://wiki.opendnssec.org/display/DOCS/Key+States#KeyStates-Publish for
    reference), then the key is, from OpenDNSSEC's point of view, not ready to
    be used, as it hasn't had time to propagate.
    
    You can still export the DS record, derived from the KSK:

    # ods-enforcer key export --zone mytld --ds --keystate publish

    Note the warning!

WARNING: No active or ready keys seen for this zone. Do not load any DS records to the parent unless you understand the possible consequences.

    Ok, let's send the DS to a file, so we can upload it:

    # ods-enforcer key export --zone mytld --ds --keystate publish >/tmp/dsset-mytld.

13. Upload the DS to the server

    # scp /tmp/dsset-mytld. admin@a.root-servers.net:

14. Notify the administrator!

    Ask the root operator to add the new DS to the root zone, and see
    how long it takes before validation starts working again for your zone.
    
15. What's with the keystate ?

    Why is the key in Publish state ? Why is OpenDNSSEC reluctant to let us
    use the key right away ?

    Was it a good idea to upload the DS already ?

    If you wait long enough, you will see this:

Keys:
Zone:                           Keytype:      State:    Date of next transition:
mytld                           KSK           ready     waiting for ds-seen
mytld                           ZSK           retire    2014-03-21 07:50:38
mytld                           ZSK           active    2014-03-21 07:54:38

    In reality, we should have waited until the key was marked
    as "ready" before we published the DS!

    Why ? There was a risk the zone information wasn't fully propagated
    (think secondaries and caches). Only once the key is marked as ready
    is it safe to upload the DS. OpenDNSSEC uses the parameters in the
    policy settings (kasp.xml) to determine this.

16. Informing OpenDNSSEC that the DS is seen in the parent zone

    Once you have seen the DS in the parent zone, and the KSK is in the
    "ready" state, then you can tell OpenDNSSEC about it.

    # ods-enforcer key list -v

Keys:
Zone:                           Keytype:      State:    Date of next transition (to):  Size:   Algorithm:  CKA_ID:                           Repository:                       Keytag:
mytld                           KSK           ready     waiting for ds-seen (active)   2048    8           0c4f577032e04e2eb34163382a4524d7  SoftHSM                           44096
mytld                           ZSK           active    2014-03-21 07:54:38 (retire)   1024    8           bbd9b3e14c3cbb0517d49f79985916bd  SoftHSM                           57634
mytld                           ZSK           publish   2014-03-21 09:02:55 (ready)    1024    8           7982538186c1b77afe84e6875f3c7bda  SoftHSM                           51991

    -v gives you the key ids, which you will need for the next step.

    Note the keyid of the KSK, which is in `ready` state.

    Now, do:

    # ods-enforcer key ds-seen --zone mytld --keytag 44096

    ... where 44096 is the keyid of the KSK in the example above.

    You will see:

    Found key with CKA_ID 0c4f577032e04e2eb34163382a4524d7
    Key 0c4f577032e04e2eb34163382a4524d7 made active
    Notifying enforcer of new database...
    Performed a HUP ods-enforcerd

    Ok, look at the keys again:

    # ods-ksmutil key list

    Note that the KSK is now marked active.