Project

General

Profile

DNS » History » Version 18

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

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 18 Marc Dequènes
To see if the zone KSK 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 18 Marc Dequènes
To have a list of KSK keys that needs publishing on the parent zone:
115
<pre>
116
dnssec-checkds <zone-name>
117
</pre>
118
119 10 Marc Dequènes
h3. KSK Rollover Workflow
120 17 Marc Dequènes
121
We use the Double-Signature method with some overlap of DS publishing.
122 10 Marc Dequènes
123 15 Marc Dequènes
Here are the states and what needs to be done:
124
* *created* state:
125
** new created key (new zone or key replacement), this key is not used yet
126
** action: wait
127
* *publish* state:
128
** the is added to the zone but not used to sign yet
129
** after the zone default TTL has passed, it is considered published
130
** action: wait for propagation
131 1 Marc Dequènes
* *active* state:
132
** the key is used for signing
133 18 Marc Dequènes
** action: export the key either (depending on the registrar):
134
*** 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)
135
*** 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)
136 15 Marc Dequènes
** action: add the key to the parent zone
137
** after the DS TTL has passed, it is considered published and the zone is secured with the key
138
** action: wait for the next rollover
139
* *inactive* state:
140
** the key is no more used to sign but still published
141
** action: remove the DS key from the parent zone
142
* *deleted* state:
143
** the key is not published anymore
144
** action: when you're sure everything went fine, purge old keys (should be automated some day)
145 11 Marc Dequènes
146
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.
147 6 Marc Dequènes
148 7 Marc Dequènes
The plan in the long run is to use CDS/CDNSKEY (RFC 7344). Some interesting reading about an implementation:
149
  https://jpmens.net/2017/09/21/parents-children-cds-cdnskey-records-and-dnssec-cds/
150 6 Marc Dequènes
151 12 Marc Dequènes
h3. Checking a Zone
152
153
Test a Zone using a DNSSEC-enabled resolver:
154
<pre>
155
dig <zone-name> +dnssec
156
</pre>
157 13 Marc Dequènes
158 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).
159
160
Test a Zone using an external web tool:
161
* http://dnssec-debugger.verisignlabs.com/
162
* http://dnsviz.net/
163
164 6 Marc Dequènes
h3. Forcing a policy change to be applied at once
165
166
Via Ansible it is possible to change the policy directly, then either wait a few hours or run _dnssec-keymgr_ manually (as _bind_ user).
167
168
h3. Unsecuring a Zone
169
170
First the DS needs to be removed from the parent zone, then we need to wait for the DS TTL to expire before unsigning.
171
172
The Ansible config can then be updated. Key materials need to be removed manually.
173
174 1 Marc Dequènes
h3. Forcing an Early Rollover
175
176
It is possible to do so: https://blog.webernetz.net/dnssec-ksk-emergency-rollover/
177 16 Marc Dequènes
178 1 Marc Dequènes
Summary:
179 16 Marc Dequènes
* create new key: *dnssec-keygen -a RSASHA512 -b 4096 -3 -f KSK <zone-name>* (in _/etc/bind/keys_ and ensuring proper permissions for Bind)
180
* resign the zone: *rndc sign <zone-name>*
181 18 Marc Dequènes
* publish the key in the parent zone (see KSK Rollover Workflow above)
182 16 Marc Dequènes
* 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)
183 9 Marc Dequènes
184
h2. Checking Servers
185
186
* "ISC EDNS Compliance Tester":https://ednscomp.isc.org/ednscomp/
187 14 Marc Dequènes
188
h2. Problems
189
190
h3. receive_secure_serial: not exact
191
192
This means the inline-signing journal is corrupted and changes to the zone cannot be applied to the signed zoned.
193
194
Workaround:
195
<pre>
196
rndc sync -clean <zone>
197
rndc stop
198
</pre>
199
then bump the zone's serial and restart Bind, it should have solved the problem.