Project

General

Profile

DNS » History » Version 27

Marc Dequènes, 2021-05-20 16:37

1 6 Marc Dequènes
{{toc}}
2
3 1 Marc Dequènes
h1. DNS
4
5
h2. Zone Management
6
7 9 Marc Dequènes
h3. Adding a Zone
8
9 26 Marc Dequènes
The zones are declared in _host_vars/<dnsserver>/dns.yml_ and the playbook _playbooks/tenants/duckcorp/dns.yml_ is in charge of updating all configurations (see the _bind9_ role documentation to understand the parameters).
10 1 Marc Dequènes
11 26 Marc Dequènes
As for the zone content:
12
* the preferred method is though the _dns4tenants_ method; in the same config above you can define git repositories for tenants containing their zones which are then automagically updated on the server when the git repo is updated (max 5min delay) (see the _dns4tenants_ role documentation to understand the parameters)
13
* *OBSOLETE* Banya service using GPG emails to update the zone; users had much problems with their MUA and the maintenance of the Ruby code was also difficult, then we are migrating them to the _dns4tenants_ method (WIP)
14
* *OBSOLETE* zone files directly written on the server in _/etc/bind/masters/_ (beware of ownership _root:bind_); there is no history and it's prone to mistake, then we are migrating them to the _dns4tenants_ method (WIP)
15
16 27 Marc Dequènes
If the zone is DNSSEC-signed, the publishing of keys in the parent zone may need to be done manually; more details below.
17 1 Marc Dequènes
18 9 Marc Dequènes
h3. Updating a Zone
19 1 Marc Dequènes
20 27 Marc Dequènes
h4. dns4tenants method
21
22
You just need to push changed in the correspondign git repo holding the zone. You don't need to care about checking, reloading or DNSSEC, all of this is done for you. It can be useful to add checks in the repo's CI though to catch errors early. In case of error the tenant will be notified by mail.
23
24
h4. Manual method
25
26 15 Marc Dequènes
Edit the file _/etc/bind/masters/<zone-name>.zone_ on the primary master (Orfeo for all zones except DuckLand zones using Elwing).
27
28
Do not forget to update the serial!
29
30
Better to check the file validity before publishing the zone:
31 2 Marc Dequènes
<pre>
32
named-checkzone <zone-name> <zone-file>
33 15 Marc Dequènes
</pre>
34 2 Marc Dequènes
35
Then to publish the zone (DNSSEC-signed zones too):
36
<pre>
37
rndc reload <zone-name>
38 1 Marc Dequènes
</pre>
39
40 9 Marc Dequènes
h3. Reseting the Zone Serial
41 7 Marc Dequènes
42 15 Marc Dequènes
The serial needs to be increased by steps, as described "in this article":http://www.microhowto.info/howto/reset_the_serial_number_of_a_dns_zone.html.
43 7 Marc Dequènes
44 1 Marc Dequènes
h2. Secure Zone Transfers
45
46
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. 
47
48
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.
49
50
You can a new key using:
51
<pre>
52 5 Marc Dequènes
dnssec-keygen -a HMAC-SHA512 -b 512 -n HOST taiste
53
</pre>
54
Take the 'Key' part in 'Ktaiste.*.private' file, to put into the configuration.
55
56
The same playbook (_playbooks/tenants/duckcorp/dns.yml_) is used to update the configuration.
57
58 15 Marc Dequènes
h2. DNSSEC
59 5 Marc Dequènes
60 23 Marc Dequènes
Here are notes about using Bind KASP (version 9.16 required).
61 5 Marc Dequènes
62 23 Marc Dequènes
All general info above about DNSSEC does not change, especially the rollover steps are similar even if the tooling change, and testing the zone is identical.
63 5 Marc Dequènes
64 23 Marc Dequènes
The Ansible _bind_ role has been updated in a branch to be able to use Bind KASP for DNSSEC. Our Ansible repository now tracks this branch 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.
65 5 Marc Dequènes
66
h3. Introduction
67
68
Better read some documentation before fiddling with the controls:
69 25 Marc Dequènes
* "Bind DNSSEC Guide":https://downloads.isc.org/isc/dnssec-guide/html/dnssec-guide.html (for general principles)
70
* "KSK Rollover":https://blog.webernetz.net/dnssec-ksk-key-rollover/ (key is created by KASP instead of using `dnssec-keymgr` but it's a good example)
71
* "Bind KASP (aka dnssec-policy)":https://kb.isc.org/v1/docs/en/dnssec-key-and-signing-policy (Bind9's new system)
72
* "Paper KASP is based on":https://nlnetlabs.nl/downloads/publications/satin2012-Schaeffer.pdf (explains the state machine)
73 1 Marc Dequènes
* "Future KSK Rollover Automation":https://www.dns.cam.ac.uk/news/2019-01-30-rollover.html
74 24 Marc Dequènes
* "CDS/CDNSKEY (RFC 7344) automation":https://jpmens.net/2017/09/21/parents-children-cds-cdnskey-records-and-dnssec-cds/
75 1 Marc Dequènes
76 23 Marc Dequènes
Key materials are created on-demand by Bind using the policy parameters, so no need to do anything outside Ansible configuration of the zones and policy parameters. Cleanup of old keys when they become obsolete or when a zone is removed is not yet done though.
77 1 Marc Dequènes
78 23 Marc Dequènes
h3. Notes about migrating from a previous version (historical)
79
80
It is important to cleanup old keys first if switching from dnssec-keymgr to dnssec-policy or old keys would get in the way.
81
82
More generally look at "this ticket tracking the problems we encountered":https://projects.duckcorp.org/issues/720
83
84
As Bind is not using the usual date-based zone serial, it can be less misleading to reset the serial before migration (see dedicated chapter above).
85
86 5 Marc Dequènes
h3. Zone Status
87
88 1 Marc Dequènes
General zone info, including the real published serial (after signing, resigning if it happens, rollovers…) and planned signing events:
89 6 Marc Dequènes
<pre>
90 1 Marc Dequènes
rndc zonestatus <zone-name>
91
</pre>
92
93 21 Marc Dequènes
h4. Zone Keys
94 7 Marc Dequènes
95 21 Marc Dequènes
To know which keys (<key-id>) are currently signing a zone (may be inactive and not deleted yet):
96 22 Marc Dequènes
<pre>
97 23 Marc Dequènes
rndc dnssec -status <zone-name>
98
</pre>
99 6 Marc Dequènes
100 23 Marc Dequènes
Keys are stored in _/etc/bind/keys_ and you can use the key ID to locate the corresponding file this way:
101 1 Marc Dequènes
<pre>
102 7 Marc Dequènes
ls /etc/bind/keys/K<zone-name>.+*+*<key-id>.key
103
</pre>
104 15 Marc Dequènes
105 6 Marc Dequènes
Inside you can read the key type (KSK/ZSK) and the lifetime schedule (so important rollover dates).
106 1 Marc Dequènes
107 23 Marc Dequènes
The KASP is in charge of the key maintenance according to the policy. It is possible to alter the timing using the _dnssec-settime_ tool in case of bugs but that should not be needed.
108
In this case, after doing the modifications, Bind needs to be notified using:
109 10 Marc Dequènes
<pre>
110 18 Marc Dequènes
rndc loadkeys <zone-name>
111 6 Marc Dequènes
</pre>
112
113
h4. Parent Zone Publishing
114
115 1 Marc Dequènes
To see if the zone KSK keys are properly published in the parent zone:
116
<pre>
117
dnssec-checkds <zone-name>
118
</pre>
119
120
h3. Key Rollover
121
122 23 Marc Dequènes
To get a view of the schedule:
123 1 Marc Dequènes
<pre>
124 23 Marc Dequènes
rndc dnssec -status <zone-name>
125 1 Marc Dequènes
</pre>
126
127 6 Marc Dequènes
To have a list of KSK keys that needs publishing on the parent zone:
128
<pre>
129
dnssec-checkds <zone-name>
130 10 Marc Dequènes
</pre>
131
132 23 Marc Dequènes
The ZSK key rollover is handled automatically by Bind (KASP), so admins have nothing to do.
133
134
The KSK rollover implies contact with the parent zone:
135
* if we do not manage the parent zone:
136
** if the parent zone handles CDS/CDNSKEY (RFC 7344) then it will grab the new DS automagically (but most TLDs do not support it yet)
137
** else a manual step to get the DS entry in their zone is needed (manually in their UI, maybe via an API)
138
* if we manage the parent zone:
139
** if the zone publishes the CDS/CDNSKEY RRs (all our zones have them) then we simply need to define the list of _dnssec_children_ in the parent zone configuration (see bind9 role documentation) and a script will make the update
140
** else we need to organize with the tenant on a method to exchange the DS
141 1 Marc Dequènes
142 24 Marc Dequènes
Then Bind needs to be informed that a new KSK is properly published in the parent zone and an obsolete KSK had been removed from the parent zone (this is unfortunately not automatic yet):
143
<pre>
144
rndc dnssec -checkds -key <new-key-id> published <zone-name>
145
rndc dnssec -checkds -key <old-key-id> withdrawn <zone-name>
146
</pre>
147
(each can be done anytime but the rollover will be completed only when both are done)
148 23 Marc Dequènes
149 10 Marc Dequènes
h3. KSK Rollover Workflow
150 17 Marc Dequènes
151 15 Marc Dequènes
We use the Double-Signature method with some overlap of DS publishing.
152 1 Marc Dequènes
153 24 Marc Dequènes
Bind's KASP uses a new system of states which does not represent steps and are not documented yet. We decided to keep the usual state names to reflect the states and try to map to the new system when we have the knowledge.
154
155 1 Marc Dequènes
Here are the states and what needs to be done:
156
* *created* state:
157
** new created key (new zone or key replacement), this key is not used yet
158
** action: wait
159
* *publish* state:
160 24 Marc Dequènes
** the key is added to the zone and used to sign but not yet published in the parent zone
161
** KASP says the key's DS is _rumoured_
162
** action: if not automated, wait for propagation, export the key (type depending on the registrar) and add it to the parent zone (Web UI, API…):
163 1 Marc Dequènes
*** DS: in digest format using the *dnssec-dsfromkey -2 <ksk-filename>* command (see previous chapter to get the absolute filename for the current KSK key, any of the _key_ or _private_ file would do)
164
*** full key: in _<ksk-filename>_ the _<key>_ is on a line formated like _<zone-name> <ttl>  IN DNSKEY <flags> <protocol> <algorithm> <key>_ (<flags>, <protocol> and <algorithm> are three numbers, the rest is the <key>; you can copy it with the spaces)
165 24 Marc Dequènes
** action: after the DS TTL has passed, check if it is well published (*dnssec-checkds <zone-name>*) and notify Bind (see *rndc dnssec -checkds* above)
166
* *active* state:
167
** the key is used to sign and published in the parent zone
168
** KASP says all states to _omnipresent_
169 12 Marc Dequènes
** action: wait for the next rollover
170 24 Marc Dequènes
* *unpublish* state:
171
** the key is still used to sign but should top being used soon
172
** KASP says the key's goal is _hidden_ and DS is _unretentive_
173
** action: if not automated, remove the DS key from the parent zone
174
** action: after the DS TTL has passed, check if it is no longer published (*dnssec-checkds <zone-name>*) and notify Bind (see *rndc dnssec -checkds* above)
175 12 Marc Dequènes
* *inactive* state:
176 24 Marc Dequènes
** the key is no longer used to sign nor published in the parent zone
177
** action: remove the key materials (since Bind does not cleanup automatically yet)
178 1 Marc Dequènes
179 24 Marc Dequènes
Currently we need to check manually when to do the KSK rollover. The coverage command above and _next key event_ in the zone info should help build a little script to warn us in time (the old one for dnssec-keymgr cannot be used anymore).
180 1 Marc Dequènes
181
h3. Checking a Zone
182
183
Test a Zone using a DNSSEC-enabled resolver:
184
<pre>
185 12 Marc Dequènes
dig <zone-name> +dnssec
186
</pre>
187
188
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).
189
190
Test a Zone using an external web tool:
191 6 Marc Dequènes
* http://dnssec-debugger.verisignlabs.com/
192 23 Marc Dequènes
* http://dnsviz.net/
193 6 Marc Dequènes
194
h3. Forcing a policy change to be applied at once
195
196 23 Marc Dequènes
Via Ansible it is possible to change the policy directly and Bind should trigger the changes automagically. Currently we have not tested a change of policy with KASP.yet. We would like to test an algorithm rollover but we're waiting for some other bugs to be fixed first.
197 6 Marc Dequènes
198 23 Marc Dequènes
h3. Unsecuring a Zone
199 6 Marc Dequènes
200
First the DS needs to be removed from the parent zone, then we need to wait for the DS TTL to expire (and it's probably better to wait a few days for Inetrnet caches to expire) before unsigning (which can be done by changing the zone's _dnssec_policy_ to _insecure_ in the Ansible configuration). It has not been tested yet since we never had the need.
201 1 Marc Dequènes
202
Key materials need to be removed manually.
203
204 23 Marc Dequènes
h3. Forcing an Early Rollover
205
206
It is possible to do so: https://blog.webernetz.net/dnssec-ksk-emergency-rollover/
207
208
You can trigger an immediate change of KSK (with <key-id> the ID of the key you wish to replace):
209
<pre>
210 9 Marc Dequènes
rndc dnssec -rollover -key <key-id> <zone-name>
211
</pre>
212
213
There is currently a bug so it may take up to a week to trigger.
214 14 Marc Dequènes
215 20 Marc Dequènes
h2. Checking Servers
216
217
* "ISC EDNS Compliance Tester":https://ednscomp.isc.org/ednscomp/
218
219
h3. DNSSEC Checks
220
221
Should return a A record and have the *ad* flag set:
222
<pre>
223
dig sigok.verteiltesysteme.net @127.0.0.1
224
</pre>
225
226
227
Should return *SERVFAIL*:
228
<pre>
229 14 Marc Dequènes
dig sigfail.verteiltesysteme.net @127.0.0.1
230
</pre>
231
232
233
h2. Problems
234
235
h3. receive_secure_serial: not exact
236
237
This means the inline-signing journal is corrupted and changes to the zone cannot be applied to the signed zoned.
238
239
Workaround:
240
<pre>
241 19 Marc Dequènes
rndc sync -clean <zone>
242
rndc stop
243
</pre>
244
then bump the zone's serial and restart Bind, it should have solved the problem.
245
246
If this does not work:
247
<pre>
248 1 Marc Dequènes
systemctl stop bind9
249
rm /var/cache/bind/masters/<zone>.zone.*
250
systemctl start bind9
251
</pre>