Project

General

Profile

DNS » History » Version 17

Marc Dequènes, 2019-09-26 07:19

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 1 Marc Dequènes
On each DNS server, master zone can be created/updated on _/etc/bind/masters/_. The ownership needs to be:
10
* _banya:_ if a user zone which should be updatable via the Banya service
11
* _root:bind_ in all other cases
12
13 15 Marc Dequènes
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.
14 1 Marc Dequènes
15 9 Marc Dequènes
h3. Updating a Zone
16 1 Marc Dequènes
17 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).
18
19
Do not forget to update the serial!
20
21
Better to check the file validity before publishing the zone:
22 2 Marc Dequènes
<pre>
23 1 Marc Dequènes
named-checkzone <zone-name> <zone-file>
24 2 Marc Dequènes
</pre>
25
26 15 Marc Dequènes
Then to publish the zone (DNSSEC-signed zones too):
27 2 Marc Dequènes
<pre>
28
rndc reload <zone-name>
29
</pre>
30
31 1 Marc Dequènes
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.
32
33 9 Marc Dequènes
h3. Reseting the Zone Serial
34 7 Marc Dequènes
35 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.
36 7 Marc Dequènes
37 1 Marc Dequènes
h2. Secure Zone Transfers
38
39
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. 
40
41
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.
42
43
You can a new key using:
44
<pre>
45 5 Marc Dequènes
dnssec-keygen -a HMAC-SHA512 -b 512 -n HOST taiste
46
</pre>
47
Take the 'Key' part in 'Ktaiste.*.private' file, to put into the configuration.
48
49
The same playbook (_playbooks/tenants/duckcorp/dns.yml_) is used to update the configuration.
50
51 15 Marc Dequènes
h2. DNSSEC
52 5 Marc Dequènes
53 15 Marc Dequènes
Here are notes about using Bind inline-signing and key management. Important fixes for inline-signing are expected in version 9.13 (so 9.14 stable), and hopefully more DNSSEC tooling improvements (like full KSK rollover scheduling).
54 5 Marc Dequènes
55
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.
56
57
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.
58
59
h3. Introduction
60
61
Better read some documentation before fiddling with the controls:
62 17 Marc Dequènes
* "Bind DNSSEC Guide":https://downloads.isc.org/isc/dnssec-guide/html/dnssec-guide.html
63
* "KSK Rollover":https://blog.webernetz.net/dnssec-ksk-key-rollover/ (key is manually created instead of using `dnssec-keymgr` but it's a good example)
64
* "Future KSK Rollover Automation":https://www.dns.cam.ac.uk/news/2019-01-30-rollover.html
65 5 Marc Dequènes
66
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).
67
68
h3. Zone Status
69
70
General zone info, including the real published serial (after signing, resigning if it happens, rollovers…) and planned signing events:
71
<pre>
72
rndc zonestatus <zone-name>
73 1 Marc Dequènes
</pre>
74 6 Marc Dequènes
75
h4. Zone Keys
76 1 Marc Dequènes
77 6 Marc Dequènes
To know which keys are currently signing a zone:
78 7 Marc Dequènes
<pre>
79 6 Marc Dequènes
rndc signing -list <zone-name>
80
</pre>
81
82 1 Marc Dequènes
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:
83
<pre>
84
ls /etc/bind/keys/K<zone-name>.+*+*<key-id>.key
85 7 Marc Dequènes
</pre>
86
87
Inside you can read the key type (KSK/ZSK) and the lifetime schedule (so important rollover dates).
88
89 16 Marc Dequènes
_dnssec-keymgr_ is in charge of the key maintenance according to the policy. It is possible to alter the timing using the _dnssec-settime_ tool, for example to schedule an emergency rollover if a key is compromised.
90 15 Marc Dequènes
In this case, after doing the modifications, Bind needs to be notififed using:
91
<pre>
92
rndc loadkeys <zone-name>
93
</pre>
94 6 Marc Dequènes
95
h4. Parent Zone Publishing
96 10 Marc Dequènes
97
To see if the zone keys are properly published in the parent zone:
98 6 Marc Dequènes
<pre>
99
dnssec-checkds <zone-name>
100
</pre>
101
(SHA-1 is obsolete, so not published)
102
103
h3. Key Rollover
104
105 10 Marc Dequènes
The ZSK key rollover is handled automatically by Bind (_dnssec-keymgr_ in crontab), so admins have nothing to do.
106
107
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.
108
109
To get a view of the schedule (past events for currently involved keys are displayed too) (beware it is using UTC):
110
<pre>
111
dnssec-coverage -K /etc/bind/keys -m 1w -d 1d -k
112 1 Marc Dequènes
</pre>
113
114 10 Marc Dequènes
h3. KSK Rollover Workflow
115 17 Marc Dequènes
116
We use the Double-Signature method with some overlap of DS publishing.
117 10 Marc Dequènes
118 15 Marc Dequènes
Here are the states and what needs to be done:
119
* *created* state:
120
** new created key (new zone or key replacement), this key is not used yet
121
** action: wait
122
* *publish* state:
123
** the is added to the zone but not used to sign yet
124
** after the zone default TTL has passed, it is considered published
125
** action: wait for propagation
126
* *active* state:
127
** the key is used for signing
128
** action: export the key in DS 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)
129
** action: add the key to the parent zone
130
** after the DS TTL has passed, it is considered published and the zone is secured with the key
131
** action: wait for the next rollover
132
* *inactive* state:
133
** the key is no more used to sign but still published
134
** action: remove the DS key from the parent zone
135
* *deleted* state:
136
** the key is not published anymore
137
** action: when you're sure everything went fine, purge old keys (should be automated some day)
138 11 Marc Dequènes
139
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.
140 6 Marc Dequènes
141 7 Marc Dequènes
The plan in the long run is to use CDS/CDNSKEY (RFC 7344). Some interesting reading about an implementation:
142
  https://jpmens.net/2017/09/21/parents-children-cds-cdnskey-records-and-dnssec-cds/
143 6 Marc Dequènes
144 12 Marc Dequènes
h3. Checking a Zone
145
146
Test a Zone using a DNSSEC-enabled resolver:
147
<pre>
148
dig <zone-name> +dnssec
149
</pre>
150 13 Marc Dequènes
151 12 Marc Dequènes
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).
152
153
Test a Zone using an external web tool:
154
* http://dnssec-debugger.verisignlabs.com/
155
* http://dnsviz.net/
156
157 6 Marc Dequènes
h3. Forcing a policy change to be applied at once
158
159
Via Ansible it is possible to change the policy directly, then either wait a few hours or run _dnssec-keymgr_ manually (as _bind_ user).
160
161
h3. Unsecuring a Zone
162
163
First the DS needs to be removed from the parent zone, then we need to wait for the DS TTL to expire before unsigning.
164
165
The Ansible config can then be updated. Key materials need to be removed manually.
166
167
h3. Forcing an Early Rollover
168 1 Marc Dequènes
169
It is possible to do so: https://blog.webernetz.net/dnssec-ksk-emergency-rollover/
170
171 16 Marc Dequènes
Summary:
172
* create new key: *dnssec-keygen -a RSASHA512 -b 4096 -3 -f KSK <zone-name>* (in _/etc/bind/keys_ and ensuring proper permissions for Bind)
173
* resign the zone: *rndc sign <zone-name>*
174
* get the DS with *dnssec-dsfromkey -2 <ksk-filename>* and publish it in the parent zone
175
* schedule removal of the old key: *dnssec-settime -D +24h <ksk-filename>* (the exact time depends on the TTL of the DS record, which is 24h for Gandi)
176 9 Marc Dequènes
177
h2. Checking Servers
178
179
* "ISC EDNS Compliance Tester":https://ednscomp.isc.org/ednscomp/
180 14 Marc Dequènes
181
h2. Problems
182
183
h3. receive_secure_serial: not exact
184
185
This means the inline-signing journal is corrupted and changes to the zone cannot be applied to the signed zoned.
186
187
Workaround:
188
<pre>
189
rndc sync -clean <zone>
190
rndc stop
191
</pre>
192
then bump the zone's serial and restart Bind, it should have solved the problem.