Agenda: opendnssec-lab2-rollover.txt

Rollover with OpenDNSSEC
------------------------

1. Make sure that your zone is validating correctly.

Things to verify (also if your zone works!)

- look at the key id of your KSK (ods-ksmutil key list -v --zone mytld)

- is BIND loading the right zone ? (compare SOA serial value in
  /usr/local/var/opendnssec/signed with that returned by
  dig @auth1.grpX.ws.nsrc.org SOA mytld)

- verify that the right DS is loaded in the root zone

  dig @a.root-servers.net DS mytld +dnssec

- compare the key ID of the DS in the root (output from above) with that of
  the key used to sign your DNSKEY RR

  dig @auth1.grpX.ws.nsrc.org DNSKEY mytld +dnssec

  (look for the key id on the RRSIG)

  Correct the problems if necessary - remember to check that the serial on the
  master is NOT less than the serial on your slave server(s) !

2. Check the key states

    # ods-ksmutil key list -v --zone mytld

You should have at least one KSK in 'publish' state, and one ZSK in 'active'
state.

3. Trigger a ZSK rollover

    # ods-ksmutil key rollover --zone mytld --keytype ZSK

    Notifying enforcer of new database...

    # tail /var/log/messages

    Wait a few seconds, then show the keys again

    # ods-ksmutil key list -v --zone mytld

    You should now see 3 keys:

    - 1 KSK in state 'ready', with a next transition of 'waiting for ds-seen'
    - 1 ZSK in state 'active' (the previous ZSK)
    - 1 new ZSK in state 'publish'

4. Now is a good time to confirm to OpenDNSSEC that the DS of the KSK is really
   visible in the parent zone

   Note: this is unrelated to the ZSK rollover - but we are keeping busy
   while OpenDNSSEC is doing its work in the background.

    Check again like earlier that your DS is visible in the parent zone

    # dig @a.root-servers.net DS mytld

    Tell OpenDNSSEC so:

    # ods-ksmutil key ds-seen --zone mytld --keytag XXXXX

    ... where XXXXX is the keytag for your KSK

    You will see output similar to this:

    Found key with CKA_ID 4ef87ddcafc78e3caf5e41964819248d
    Key 4ef87ddcafc78e3caf5e41964819248d made active
    Notifying enforcer of new database...

    Look a the keys again:

    # ods-ksmutil key list -v

    ... notice that the KSK is now in 'active' state.

    But while you were doing this, the ZSK that was previously active is now in
    'retire' state, and the ZSK in 'publish' state is now in 'active' state.

    Effectively, OpenDNSSEC is now rolling ZSKs automatically. It will do this
    without your help, but you can always trigger a rollover for emergency
    reasons.

5. Testing a KSK rollover

    Take a look at the existing keys:

    # ods-ksmutil key list -v

    Now, let's issue a rollover. Remember, KSK rollovers can't happen
    automatically in most cases, so you will need to help OpenDNSSEC by:

    - exporting the DS of the new key once you initiate the rollover
      (ods-ksmutil key export --zone mytld --keystate ...)

    - telling OpenDNSSEC when you can see that the root/parent has included
      your DS in their zone
      (ods-ksmutil key ds-seen --zone mytld --keytag XXXXX)

    Ok let's rollover:

    # ods-ksmutil key rollover --keytype KSK --zone mytld

    Look at the key states:

    # ods-ksmutil key list -v

    We leave the rest of this exercise up to you :)


6. See what rollovers are automatically planned, and when

    # ods-ksmutil rollover list

    key rollover --zone|-z name [--keytype type]
    key rollover --policy|-p name [--keytype type]
    key ds-seen --keytag|-x keytag
    key ds-seen --cka_id|-k ckaid
    key generate --policy|-p name --interval|-n interval