Agenda: dnssec-bind-manual-signing-howto.txt

File dnssec-bind-manual-signing-howto.txt, 6.5 KB (added by admin, 6 years ago)
Line 
1*** ON YOUR AUTHORITATIVE SERVER ***
2
31. Change to the directory where the zone resides, and make a backup
4   of the zone (assuming it's called "mytld"), just in case
5
6    $ cd /etc/namedb/master
7    $ sudo cp mytld mytld.backup
8
9  Also create a directory for the keys to live in, and let's create them
10
11    $ sudo mkdir /etc/namedb/keys
12    $ sudo chown bind /etc/namedb/keys
13
14    $ cd /etc/namedb/keys
15
162. Generate first key pair (Zone Signing Key)
17
18    $ sudo dnssec-keygen -a RSASHA1 -b 1024 -n ZONE mytld
19
20    The output will be something like:
21
22Generating key pair....................++++++ ...........................................................................................................++++++
23Kmytld.+005+51333
24
254. Generate second key pair (Key Signing Key)
26
27    $ sudo dnssec-keygen -f KSK -a RSASHA1 -b 2048 -n ZONE mytld
28
29    Again you will see output similar to this:
30
31Generating key pair.............................................+++ ..........................................................................+++
32Kmytld.+005+52159
33
344. Let's look at the keys:
35
36    # ls -l Kmytld.+005+5*
37    -rw-r--r--  1 root  wheel   203 Nov 29 00:07 Kmytld.+005+51333.key
38    -rw-------  1 root  wheel   937 Nov 29 00:07 Kmytld.+005+51333.private
39    -rw-r--r--  1 root  wheel   247 Nov 29 00:07 Kmytld.+005+52159.key
40    -rw-------  1 root  wheel  1125 Nov 29 00:07 Kmytld.+005+52159.private
41
424. Add the public keys to the end of the zone file:
43
44    Edit the zone file for "mytld" and add the keys at the end:
45
46    $ cd /etc/namedb/master
47
48    (edit the file "mytld" or whatever name you picked, and add the
49    lines corresponding to your keys)
50
51    $ sudo ee mytld
52
53    ; Keys to be published in DNSKEY RRset
54
55    $include "/etc/namedb/keys/Kmytld.+005+51333.key"     ; ZSK
56    $include "/etc/namedb/keys/Kmytld.+005+52159.key"     ; KSK
57
58    Increment the serial number.
59    Save and exit.
60
615. Sign the zone with the keys
62
63    $ cd /etc/namedb/keys
64    $ sudo dnssec-signzone -o mytld ../master/mytld
65
66    The output will look something like:
67
68Verifying the zone using the following algorithms: RSASHA1.
69Zone signing complete:
70Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
71                    ZSKs: 1 active, 0 stand-by, 0 revoked
72../master/mytld.signed
73
74    NOTE: that we don't need to specifiy which keys we'll be using - by
75    default dnssec-signzone will sign using the keys it finds listed in the
76    zone (those we added via the $include statement in step 4).
77
78    If you wanted to explicitly specify which keys to use, you'd write
79    something like (don't run this):
80
81    $ sudo dnssec-signzone -o mytld -k Kmytld.+005+52159 ../master/mytld Kmytld.+005+51333
82
83
84
85    The signed zone has been written out in the master/ directory, sot let's
86    check it out:
87
88    # cd /etc/namedb/master/
89    # ls -l mytld*
90
91    -rw-r--r--  1 root  wheel   292 Nov 29 00:08 mytld
92    -rw-r--r--  1 root  wheel   292 Nov 29 00:10 mytld.backup
93    -rw-r--r--  1 root  wheel  4294 Nov 29 00:20 mytld.signed
94
95    Take a look at the zone contents, and observe the new records and
96    signatures.
97
986. Notice that a set of DS records has been generated, and is ready to
99   be communicated to your parent zone:
100
101    $ cd /etc/namedb/keys/
102    $ ls -l dsset-*
103
104    -rw-r--r--  1 root  wheel  155 Nov 29 00:22 dsset-mytld.
105
106   Look at the contents of the dsset:
107
108    $ cat dsset-mytld.
109
110    You should see two lines, one for each hashing algorithm used on
111    the KSK.
112
1137. Change the /etc/namedb/named.conf definition that loads the zone, to point
114   to the signed zone:
115
116    $ sudo ee /etc/namedb/named.conf
117
118    zone "mytld" {
119            type master;
120            file "/etc/namedb/master/mytld.signed"; // load the signed zone
121    };
122
1238. Also in the named.conf, enable dnssec (for the authoritative part):
124
125    ... in the options { .. }; section, add the following
126
127    dnssec-enable yes;
128
1299. Reconfigure/restart your nameserver
130
131    $ sudo rndc reconfig
132
133    You may also want to, but it is probably not necessary, do:
134
135    $ sudo rndc reload mytld
136
137    ... to "force" a reload of the zone. reconfig should normally
138    do this, but it doesn't hurt :)
139
14010. Test that the nameserver is answering with DNSSEC records:
141
142    $ dig @127.0.0.1 mytld SOA +dnssec
143
14411. Now you need to make sure that your slave has ALSO configured their
145    nameserver to enable dnssec in their configuration (step 8). They
146    should have done it since they are working on the same lab, but check
147    anyway!
148
149    To test:
150
151    # dig @10.10.Y.1 mytld SOA +dnssec
152
153    ... where Y is the IP of the partner you picked to be slave for your
154    domain - this could be the instructor, check with them.
155
15612. You now need to communicate the DS to your parent
157
158   Talk to your root manager on the way to communicate the DS.
159   It could be using SCP or using a web interface.
160
161    a) if using the RZM:
162
163    Go to https://rzm.dnssek.org/
164
165    Login (you should have signed up earlier)
166
167    Check to see under Trust Anchor Details that your DS has automatically
168    appeared AND matches. It is NOT automatically activated - the only thing
169    the the RZM has done is "grab" the key from you and is waiting for your
170    confirmation to enable th DS in the parent zone.
171
172    b) if not using the RZM:
173
174   If your root manager says to use scp, do as follows:
175
176   $ cd /etc/namedb/keys
177   $ scp dsset-mytld. adm@a.root-servers.net:
178
179   ... this will copy the file "dsset-mytld." into the "adm" user directory
180   on the a.root-server, where the root manager will include it into the root
181   zone for signing.
182   
183   Notify them when you have uploaded the file if using the "scp" method.
184
18513. Wait a few minutes, until you are certain that the DS is included in
186    the parent (root) zone.
187   
188    Then, using dig:
189
190   dig @a.root-servers.net DS mytld.
191
192   ... then you can begin to test validation!
193
19414. Test that the AD bit is set:
195
196    # dig @10.10.0.230 +dnssec www.MYTLD.
197
198    Is it ?
199
200    If not, note that the root manager may not have necessarily signed the
201    root zone with your DS included yet, OR due to the *negative TTL*, the
202    DS record may not be in the cache of the resolver. You may have to wait,
203    but check with your root manager, and you can always check at the root:
204
205    # dig @a.root-servers.net DS mytld.
206
207    ... to verify that the DS is published. Then it's a matter of waiting
208    for the cache to expire on the resolver, before you can verify your
209    signatures.
210
211    Alternatively, don't wait and proceed to enable validation in your own
212    resolver (resolv.grpX.ws.nsrc.org) - see the relevant lab!