Agenda: opendnssec-lab2-rollover.txt

File opendnssec-lab2-rollover.txt, 3.5 KB (added by admin, 6 years ago)
Line 
1Rollover with OpenDNSSEC
2------------------------
3
41. Make sure that your zone is validating correctly.
5
6Things to verify (also if your zone works!)
7
8- look at the key id of your KSK (ods-ksmutil key list -v --zone mytld)
9
10- is BIND loading the right zone ? (compare SOA serial value in
11  /usr/local/var/opendnssec/signed with that returned by
12  dig @auth1.grpX.ws.nsrc.org SOA mytld)
13
14- verify that the right DS is loaded in the root zone
15
16  dig @a.root-servers.net DS mytld +dnssec
17
18- compare the key ID of the DS in the root (output from above) with that of
19  the key used to sign your DNSKEY RR
20
21  dig @auth1.grpX.ws.nsrc.org DNSKEY mytld +dnssec
22
23  (look for the key id on the RRSIG)
24
25  Correct the problems if necessary - remember to check that the serial on the
26  master is NOT less than the serial on your slave server(s) !
27
282. Check the key states
29
30    # ods-ksmutil key list -v --zone mytld
31
32You should have at least one KSK in 'publish' state, and one ZSK in 'active'
33state.
34
353. Trigger a ZSK rollover
36
37    # ods-ksmutil key rollover --zone mytld --keytype ZSK
38
39    Notifying enforcer of new database...
40
41    # tail /var/log/messages
42
43    Wait a few seconds, then show the keys again
44
45    # ods-ksmutil key list -v --zone mytld
46
47    You should now see 3 keys:
48
49    - 1 KSK in state 'ready', with a next transition of 'waiting for ds-seen'
50    - 1 ZSK in state 'active' (the previous ZSK)
51    - 1 new ZSK in state 'publish'
52
534. Now is a good time to confirm to OpenDNSSEC that the DS of the KSK is really
54   visible in the parent zone
55
56   Note: this is unrelated to the ZSK rollover - but we are keeping busy
57   while OpenDNSSEC is doing its work in the background.
58
59    Check again like earlier that your DS is visible in the parent zone
60
61    # dig @a.root-servers.net DS mytld
62
63    Tell OpenDNSSEC so:
64
65    # ods-ksmutil key ds-seen --zone mytld --keytag XXXXX
66
67    ... where XXXXX is the keytag for your KSK
68
69    You will see output similar to this:
70
71    Found key with CKA_ID 4ef87ddcafc78e3caf5e41964819248d
72    Key 4ef87ddcafc78e3caf5e41964819248d made active
73    Notifying enforcer of new database...
74
75    Look a the keys again:
76
77    # ods-ksmutil key list -v
78
79    ... notice that the KSK is now in 'active' state.
80
81    But while you were doing this, the ZSK that was previously active is now in
82    'retire' state, and the ZSK in 'publish' state is now in 'active' state.
83
84    Effectively, OpenDNSSEC is now rolling ZSKs automatically. It will do this
85    without your help, but you can always trigger a rollover for emergency
86    reasons.
87
885. Testing a KSK rollover
89
90    Take a look at the existing keys:
91
92    # ods-ksmutil key list -v
93
94    Now, let's issue a rollover. Remember, KSK rollovers can't happen
95    automatically in most cases, so you will need to help OpenDNSSEC by:
96
97    - exporting the DS of the new key once you initiate the rollover
98      (ods-ksmutil key export --zone mytld --keystate ...)
99
100    - telling OpenDNSSEC when you can see that the root/parent has included
101      your DS in their zone
102      (ods-ksmutil key ds-seen --zone mytld --keytag XXXXX)
103
104    Ok let's rollover:
105
106    # ods-ksmutil key rollover --keytype KSK --zone mytld
107
108    Look at the key states:
109
110    # ods-ksmutil key list -v
111
112    We leave the rest of this exercise up to you :)
113
114
1156. See what rollovers are automatically planned, and when
116
117    # ods-ksmutil rollover list
118
119    key rollover --zone|-z name [--keytype type]
120    key rollover --policy|-p name [--keytype type]
121    key ds-seen --keytag|-x keytag
122    key ds-seen --cka_id|-k ckaid
123    key generate --policy|-p name --interval|-n interval
124