Agenda: opendnssec-lab1.txt

File opendnssec-lab1.txt, 10.7 KB (added by trac, 5 years ago)
Line 
1Zone signing with OpenDNSSEC - part 1
2
31. Initialize the Software "Hardware Security Module"
4
5    Start by becoming root for this session (or use sudo when required)
6
7    $ sudo -s
8    #
9
10    # softhsm --init-token --slot 0 --label OpenDNSSEC
11
12    (use '1234' for both questions below):
13
14    The SO PIN must have a length between 4 and 255 characters.
15    Enter SO PIN: ****
16    The user PIN must have a length between 4 and 255 characters.
17    Enter user PIN: ****
18    The token has been initialized.
19
20    # softhsm --show-slots
21
22    Create configuration files for OpenDNSSEC by making a copy
23    of the samples distributed with the package:
24
25      # cd /usr/local/etc/opendnssec
26      # cp kasp.xml.sample kasp.xml
27      # cp conf.xml.sample conf.xml
28      # cp addns.xml.sample addns.xml
29      # cp zonelist.xml.sample zonelist.xml
30      # chmod 644 *xml
31
322. Change the default Policy to use NSEC instead of NSEC3:
33
34    Edit /usr/local/etc/opendnssec/kasp.xml
35
36    Find this section, and remove all the lines from <NSEC3> ... </NSEC3>
37
38    <NSEC3>
39        <!-- <OptOut/> -->
40        <Resalt>P100D</Resalt>
41        <Hash>
42            <Algorithm>1</Algorithm>
43            <Iterations>5</Iterations>
44            <Salt length="8"/>
45        </Hash>
46    </NSEC3>
47
48    ... and replace them with this single line:
49
50    <NSEC/>
51
52    Save & exit.
53
54    Also, set the correct path for the libsofthsm.so in the conf.xml:
55
56    Change
57
58<Module>/usr/local/lib/libsofthsm.so</Module>
59
60to
61
62<Module>/usr/local/lib/softhsm/libsofthsm.so</Module>
63
64    In the same file, find the line:
65
66<Datastore><SQLite>/usr/local/var/opendnssec/kasp.db</SQLite></Datastore>
67
68    Remove it, and instead, add:
69
70<Datastore>
71    <MySQL>
72        <Host port="3306">localhost</Host>
73        <Database>opendnssec</Database>
74        <Username>root</Username>
75        <Password></Password>
76    </MySQL>
77</Datastore>
78
79
803. Start MySQL and create the database
81
82    Edit /etc/rc.conf, and add:
83
84    mysql_enable="YES"
85
86    Save and exit the file, then run:
87
88    # service mysql-server start
89
90    You should see:
91
92    Starting mysql.
93
94    Create the database:
95
96    # echo "create database opendnssec" | mysql
97
984. Initialize the KSM
99
100    # ods-ksmutil setup
101
102*WARNING* This will erase all data in the database; are you sure? [y/N] y
103Enter password:
104
105    Just press <ENTER> when asked for the password. You will then see:
106
107    zonelist filename set to /usr/local/etc/opendnssec/zonelist.xml.
108    kasp filename set to /usr/local/etc/opendnssec/kasp.xml.
109    Repository SoftHSM found
110    No Maximum Capacity set.
111    RequireBackup NOT set; please make sure that you know the potential problems of using keys which are not recoverable
112    INFO: The XML in /usr/local/etc/opendnssec/conf.xml is valid
113    INFO: The XML in /usr/local/etc/opendnssec/zonelist.xml is valid
114    INFO: The XML in /usr/local/etc/opendnssec/kasp.xml is valid
115    Policy default found
116
1175. Install a copy of the unsigned zone for OpenDNSSEC to sign
118
119    Earlier, we made a backup copy of our zone, before it was signed
120    by BIND9. We are going to use that backup copy now and make it
121    available to OpenDNSSEC.
122
123          # cd /etc/namedb/master
124          # cp mytld.backup /usr/local/var/opendnssec/unsigned/mytld
125
126    Increment the serial in the mytld file, so that it's up-to-date
127    (YYYYMMDDXY).
128
1296. Add the zone to OpenDNSSEC's database:
130
131    # ods-ksmutil zone add --zone mytld
132
133    zonelist filename set to /usr/local/etc/opendnssec/zonelist.xml.
134    Imported zone: mytld
135
1367. Start OpenDNSSEC!
137
138    Add this to /etc/rc.conf
139
140    opendnssec_enable="YES"
141
142    Save the file and exit.
143
144    Now, start the service:
145
146    # service opendnssec start
147
148    You will see:
149
150Starting enforcer...
151OpenDNSSEC ods-enforcerd started (version 1.4.3), pid 2923
152Starting signer engine...
153OpenDNSSEC signer engine version 1.4.3
154Engine running.
155
156    # ps ax | grep ods
157
158    41588  ??  SsJ    0:00.11 /usr/local/sbin/ods-enforcerd
159    41593  ??  SsJ    0:00.07 /usr/local/sbin/ods-signerd
160
1618. Check that the zone is signed
162
163    # ls -l /usr/local/var/opendnssec/signed
164
165    -rw-r--r--  1 root  wheel  2621 Feb 19 09:10 mytld
166
167    Take a look at the contents of the zone - note the key ids for
168    the KSK and ZSK.
169
170    If for some reason, you don't see a file in this directory
171    (/usr/local/var/opendnssec/signed/), then force the signer to sign:
172
173    # ods-signer sign mytld
174
1759. Moment of reflection
176
177    Ok, so now the zone is signed with OpenDNSSEC - do notice that the
178    zone was signed, but you didn't issue any commands to generate keys.
179
180    List the keys currently managed by OpenDNSSEC:
181
182    # ods-ksmutil key list
183
184Keys:
185Zone:                           Keytype:      State:    Date of next transition:
186mytld                           KSK           publish   2014-03-21 04:25:30
187mytld                           ZSK           active    2014-03-21 04:32:30
188
189    Notice that two keys have just been created by OpenDNSSEC, on the fly.
190
191    But BIND is still loading the zone that was signed earlier (either
192    manually or using the inline signer) - can we just modify the named.conf
193    definition and point to the signed zone instead ?
194
195    Which KSK is currently being used ? And which DS record is published
196    in the parent zone ?
197
198    Would the resolvers be able to verify the signatures on the zone
199    signed with OpenDNSSEC ?  Why not ? What would you have to do for
200    it to work (there are several possible answers)
201
202    If you don't care about the validation problem, then you can proceed
203    with the rest of this lab.
204
20510. Tell BIND to load the new zone
206
207    Modify /etc/namedb/named.conf, and change the zone definition for "mytld"
208    so it looks like this (REMOVE auto-dnssec, etc...)
209
210zone "mytld" {
211    file "/usr/local/var/opendnssec/signed/mytld";  // <--- Change path
212    type master;
213    key-directory "/etc/namedb/keys";   // <--- Remove if there
214    auto-dnssec maintain;               // <--- Remove if there
215    inline-signing yes;                 // <--- Remove if there
216};
217
218    Now, BIND is back to being a "passive" nameserver that doesn't sign
219    the zone - it just serves the zone signed by OpenDNSSEC.
220
221    Restart named:
222
223    # service named restart
224
225    Check the logs in /etc/namedb/log/general to make sure that the zone
226    is loading correctly.
227
228    Now, validation will probably fail for those trying to look up data
229    in your zone. Wait a few minutes, and try to lookup a record in your
230    zone:
231
232    # dig @127.0.0.1 www.mytld +dnssec
233
234    What do you notice ?
235
23611. OpenDNSSEC reload BIND
237
238    Even better, you can have OpenDNSSEC tell BIND to reload the zone when
239    it has been signed - like this, no need to manually reload.
240
241    To do this, modify /usr/local/etc/opendnssec/conf.xml
242
243    Find the lines:
244
245<!--
246                <NotifyCommand>/usr/sbin/rndc reload %zone</NotifyCommand>
247-->
248
249    ... remove the comments (the lines '<!--' and '-->') before and after.
250
251    Save the file, and restart OpenDNSSEC:
252
253    # ods-control stop
254    ...
255    # ods-control start
256
257
25812. Export the DS, ready to upload:
259
260    Verify the state of the KSK at this stage:
261
262    # ods-ksmutil key list
263
264    Note the state that the KSK is in.
265
266    If it is still in publish state (see
267    https://wiki.opendnssec.org/display/DOCS/Key+States#KeyStates-Publish for
268    reference), then the key is, from OpenDNSSEC's point of view, not ready to
269    be used, as it hasn't had time to propagate.
270   
271    You can still export the DS record, derived from the KSK:
272
273    # ods-ksmutil key export --zone mytld --ds --keystate publish
274
275    Note the warning!
276
277WARNING: No active or ready keys seen for this zone. Do not load any DS records to the parent unless you understand the possible consequences.
278
279    Ok, let's send the DS to a file, so we can upload it:
280
281    # ods-ksmutil key export --zone mytld --ds --keystate publish >/tmp/dsset-mytld.
282
28313. Upload the DS to the server
284
285    If you're not using the web interface:
286
287    # scp /tmp/dsset-mytld. sysadm@a.root-servers.net:
288
28914. Notify the administrator!
290
291    Ask the root operator to add the new DS to the root zone, and see
292    how long it takes before validation starts working again for your zone.
293   
294    ... or if using the web interface:
295
296    Log into https://rzm.dnssek.org and fix the DS records by verifying
297    the "eyed" DS records and checking them and then clicking "Update".
298    After a few minutes for caches, the resolver should validate.
299    If you have problems, ask instructor to flush the cache.
300
30115. What's with the keystate ?
302
303    Why is the key in Publish state ? Why is OpenDNSSEC reluctant to let us
304    use the key right away ?
305
306    Was it a good idea to upload the DS already ?
307
308    If you wait long enough, you will see this:
309
310Keys:
311Zone:                           Keytype:      State:    Date of next transition:
312mytld                           KSK           ready     waiting for ds-seen
313mytld                           ZSK           retire    2014-03-21 07:50:38
314mytld                           ZSK           active    2014-03-21 07:54:38
315
316    In reality, we should have waited until the key was marked
317    as "ready" before we published the DS!
318
319    Why ? There was a risk the zone information wasn't fully propagated
320    (think secondaries and caches). Only once the key is marked as ready
321    is it safe to upload the DS. OpenDNSSEC uses the parameters in the
322    policy settings (kasp.xml) to determine this.
323
32416. Informing OpenDNSSEC that the DS is seen in the parent zone
325
326    Once you have seen the DS in the parent zone, and the KSK is in the
327    "ready" state, then you can tell OpenDNSSEC about it.
328
329    # ods-ksmutil key list -v
330
331Keys:
332Zone:                           Keytype:      State:    Date of next transition (to):  Size:   Algorithm:  CKA_ID:                           Repository:                       Keytag:
333mytld                           KSK           ready     waiting for ds-seen (active)   2048    8           0c4f577032e04e2eb34163382a4524d7  SoftHSM                           44096
334mytld                           ZSK           active    2014-03-21 07:54:38 (retire)   1024    8           bbd9b3e14c3cbb0517d49f79985916bd  SoftHSM                           57634
335mytld                           ZSK           publish   2014-03-21 09:02:55 (ready)    1024    8           7982538186c1b77afe84e6875f3c7bda  SoftHSM                           51991
336
337    -v gives you the key ids, which you will need for the next step.
338
339    Note the keyid of the KSK, which is in `ready` state.
340
341    Now, do:
342
343    # ods-ksmutil key ds-seen --zone mytld --keytag 44096
344
345    ... where 44096 is the keyid of the KSK in the example above.
346
347    You will see:
348
349    Found key with CKA_ID 0c4f577032e04e2eb34163382a4524d7
350    Key 0c4f577032e04e2eb34163382a4524d7 made active
351    Notifying enforcer of new database...
352    Performed a HUP ods-enforcerd
353
354    Ok, look at the keys again:
355
356    # ods-ksmutil key list
357
358    Note that the KSK is now marked active.