Project

General

Profile

DNS » History » Version 8

Marc Dequènes, 2019-01-01 10:15

1 6 Marc Dequènes
{{toc}}
2
3 1 Marc Dequènes
h1. DNS
4
5
h2. Zone Management
6
7
On each DNS server, master zone can be created/updated on _/etc/bind/masters/_. The ownership needs to be:
8
* _banya:_ if a user zone which should be updatable via the Banya service
9
* _root:bind_ in all other cases
10
11
The zone is declared in _host_vars/_dnsserver_/dns.yml_ and the playbook _playbooks/tenants/duckcorp/dns.yml_ is in charge of updating all configurations. Only the zone content is not Ansible managed.
12
13 2 Marc Dequènes
Better to check the file validity before updating the zone:
14
<pre>
15
named-checkzone <zone-name> <zone-file>
16
</pre>
17 1 Marc Dequènes
18 7 Marc Dequènes
Then to update the zone, if DNSSEC-signed (except on _Elwing_, use the usual reload command below, more info in the DNSSEC chapter):
19 2 Marc Dequènes
<pre>
20
ods-signer sign <zone-name>
21
</pre>
22
else:
23
<pre>
24
rndc reload <zone-name>
25
</pre>
26
27
In case the zone is DNSSEC-signed, the publishing of keys in the parent zone is to be done manually (not automated yet); more details below.
28 1 Marc Dequènes
29 7 Marc Dequènes
h2. Reseting the zone serial
30
31
See: http://www.microhowto.info/howto/reset_the_serial_number_of_a_dns_zone.html
32
33 1 Marc Dequènes
h2. Secure Zone Transfers
34
35
To secure zone transfers, a TSIG key needs to be created and added on both sides. Beware the key name *must* be identical on both side. 
36
37
DNS server groups (servers allowed to request transfer) and keys can be defined in _host_vars/<dnsserver>/dns.yml_ and _host_vars/<dnsserver>/dns.vault.yml_ respectively. If they are to be used on all servers, then you can declare them in _group_vars/dns_servers/dns.yml_ and _group_vars/dns_servers/dns.vault.yml_ respectively.
38
39
You can a new key using:
40
<pre>
41
dnssec-keygen -a HMAC-SHA512 -b 512 -n HOST taiste
42
</pre>
43
Take the 'Key' part in 'Ktaiste.*.private' file, to put into the configuration.
44
45
The same playbook (_playbooks/tenants/duckcorp/dns.yml_) is used to update the configuration.
46
47 6 Marc Dequènes
h2. DNSSEC (with OpenDNSSEC, all server except Elwing)
48 1 Marc Dequènes
49 3 Marc Dequènes
h3. Introduction
50
51
Better read some documentation before fiddling with the controls:
52
* "Supported rollover methods with OpenDNSSEC":https://wiki.opendnssec.org/display/DOCS/Key+Rollovers
53
* "Explanation about the OpenDNSSEC key states":https://wiki.opendnssec.org/display/DOCS/Key+States
54
* "Deeper explanation about the OpenDNSSEC key states":https://wiki.opendnssec.org/display/DOCS20/Key+States+Explained
55
56
List of keys with states and IDs:
57
<pre>
58
ods-enforcer key list -v
59
</pre>
60
61
List of planned rollover dates:
62
<pre>
63
ods-enforcer rollover list
64
</pre>
65
66
h3. Key Rollover
67
68
The ZSK key rollover is handled automatically by OpenDNSSEC, so admins have nothing to do.
69
70
The KSK rollover implies contact with the parent zone and a manual step to get the DS entry in their zone is needed. 
71
72
h3. KSK Rollover Workflow
73
74
Here are the states and what needs to be done:
75
* *publish* state:
76
** when a new key is created, either for a new zone of to replace an old key, this key is added to the zone but not used to sign yet
77
** action: wait
78
* *ready* state:
79
** the new zone, containing the key, is considered propagated, but not used to sign yet
80 4 Marc Dequènes
** action: export the key, either using the DNSKEY or DS format depending on the provider (*ods-enforcer key export -z <zone-name> --keytype KSK --keystate ready* for the DNSKEY, or add *--ds* for the DS)
81
** action: add the key to the parent zone
82 1 Marc Dequènes
** action: wait for the key to appear in the parent zone (*host -t DS -r <zone-name> $(host -t NS <tld> | grep "name server" | head -n 1 | cut -d" " -f4)*)
83 4 Marc Dequènes
** action: notify OpenDNSSEC (*ods-enforcer key ds-seen -z <zone-name> --cka_id <key-id>*)
84
* *active* state:
85
** the key is used for signing
86
** action: wait for the next rollover
87
* *retire* state:
88
** the key is no more used to sign but still advertized
89
** action: remove the key from the parent zone
90 5 Marc Dequènes
** action: wait for the key to disappear from the parent zone (*host -t DS -r <zone-name> $(host -t NS <zone-tld> | grep "name server" | head -n 1 | cut -d" " -f4)*)
91 4 Marc Dequènes
** action: notify OpenDNSSEC (*ods-enforcer key ds-gone -z <zone-name> --cka_id <key-id>*)
92 5 Marc Dequènes
** action: when you're sure everything went fine, purge old keys (*ods-enforcer key purge --policy default*)
93 1 Marc Dequènes
94 5 Marc Dequènes
h3. Checking a Zone
95
96
Test a Zone using a DNSSEC-enabled resolver:
97
<pre>
98
dig <zone-name> +dnssec
99
</pre>
100
You need to get the ad flag. If you get the aa flag, then you're interrogating one of the official NS for the zone, then try on another server to be sure your configuration is OK (remotely with *@<server>* as first command option).
101
102
Test a Zone using an external web tool:
103
* http://dnssec-debugger.verisignlabs.com/
104
* http://dnsviz.net/
105
106
h3. Forcing a policy change to be applied at once
107
108
<pre>
109
ods-enforcer enforce
110
</pre>
111
112
h3. Unsecuring a Zone
113
114
If you plan to continue using the zone, better not remove DNSSEC support at once or until all DNSSEC information leaves the caches on the Internet problems are to be expected.
115
116
A special *unsigned* policy has been added to the _opendnssec_ Ansible role. It was created using the specifications in the OpenDNSSEC documentation but has never been tested.
117
118
In Ansible you need to affect this policy to your zone and deploy. Then follow the KSK rollover procedure until all keys have been retired. Then you can unconfigure DNSSEC for the zone.
119
120
To buy some time you might try to force an early rollover (see below).
121
122
h3. Forcing an Early Rollover
123
124
<pre>
125 1 Marc Dequènes
ods-enforcer key rollover --zone <zone-name> --keytype ksk
126 6 Marc Dequènes
</pre>
127
128 1 Marc Dequènes
h2. DNSSEC (with Bind, only Elwing)
129 6 Marc Dequènes
130 7 Marc Dequènes
Here are notes about using Bind inline-signing and key management in place of OpenDNSSEC. Until this is deemed stable enough and well tested, this will only affect DNSSEC-enabled zones on Elwing. Important fixes for inline-signing are expected in version 9.13 (so 9.14 stable), and hopefully more DNSSEC tooling improvements.
131 6 Marc Dequènes
132
All general info above about DNSSEC does not change, expecially the rollover steps are similar even if the tooling change, and testing the zone is identical.
133
134
The Ansible _bind_ role has been updated in a branch to be able to use Bind directly for DNSSEC. Our Ansible repository now tracks this branch (which still supports OpenDNSSEC) and add the necessary parameters to use it. Please look at the role's documentation to understand the inner technical details, this page is about administration of the solution.
135 1 Marc Dequènes
136
h3. Introduction
137
138 7 Marc Dequènes
Better read some documentation before fiddling with the controls:
139
* https://ftp.isc.org/isc/dnssec-guide/html/dnssec-guide.html
140
* https://kb.isc.org/docs/aa-00711
141
* https://securityblog.switch.ch/2014/11/13/dnssec-signing-your-domain-with-bind-inline-signing/
142 6 Marc Dequènes
143 7 Marc Dequènes
Key materials are initially created by the role when a zone is declared in Ansible, so no need to do anything outside Ansible. Cleanup when a zone is removed is not yet done though. As Bind is not using the usual date-based zone serial, it can be less misleading to reset the serial (see dedicated chapter above).
144
145 6 Marc Dequènes
General zone info, including the real published serial (after signing, resigning if it happens, rollovers…) and planned signing events:
146
<pre>
147
rndc zonestatus <zone-name>
148
</pre>
149
150
To know which keys are currently signing a zone:
151
<pre>
152
rndc signing -list <zone-name>
153
</pre>
154
155
There is no way yet to know which is the KSK or ZSK without looking at the key materials. Keys are stored in _/etc/bind/keys_ and you can use the key ID to locate the corresponding file this way:
156
<pre>
157 8 Marc Dequènes
ls /etc/bind/keys/K<zone-name>.+*+*<key-id>.key
158 6 Marc Dequènes
</pre>
159
160
Inside you can read the key type (KSK/ZSK) and the lifetime schedule (so important rollover dates).
161
162
*DO NOT CHANGE KEY INFORMATION !!!* Do not even use the _dnssec-settime_ tool directly. _dnssec-keymgr_ is in charge of the key maintenance according to the policy. Read more about rollover below.
163
164
h3. Key Rollover
165
166
The ZSK key rollover is handled automatically by Bind (_dnssec-keymgr_ in crontab), so admins have nothing to do.
167
168
The KSK rollover implies contact with the parent zone and a manual step to get the DS entry in their zone is needed. Creating the new keys and planning the change is also done automatically using the same tool.
169
170
To get a view of the schedule (past events for currently involved keys are displayed too) (beware it is using UTC):
171
<pre>
172
dnssec-coverage -K /etc/bind/keys -m 1w -d 1d -k
173
</pre>
174
175
h3. KSK Rollover Workflow
176
177 1 Marc Dequènes
The workflow is the same except there is no way to notify bind a change occurred, thus we *must* do the rollover in time or update the policy to allow more time (via Ansible parameters).
178
179 6 Marc Dequènes
Currently we need to check manually when to do the KSK rollover. The command above and _next key event_ in the zone info should help build a little script to warn us in time.
180
181 7 Marc Dequènes
The plan in the long run is to use CDS/CDNSKEY (RFC 7344). Some interesting reading about an implementation:
182
  https://jpmens.net/2017/09/21/parents-children-cds-cdnskey-records-and-dnssec-cds/
183 6 Marc Dequènes
184
h3. Forcing a policy change to be applied at once
185
186
Via Ansible it is possible to change the policy directly, then either wait a few hours or run _dnssec-keymgr_ manually (as _bind_ user).
187
188
h3. Unsecuring a Zone
189
190
First the DS needs to be removed from the parent zone, then we need to wait for the DS TTL to expire before unsigning.
191
192
The Ansible config can then be updated. Key materials need to be removed manually.
193
194
h3. Forcing an Early Rollover
195
196
Currently I'm not sure how it would interact with the _dnssec-keymgr_ operations so I need to test.
197
198
It is possible to do so: https://blog.webernetz.net/dnssec-ksk-emergency-rollover/
199
200
In our case we already do have pre-generated waiting keys scheduled to be injected, so changing the timing of the current key to reduce its lifetime and rerunning _dnssec-keymgr_ manually (as _bind_ user) should do the trick, but I need to test.