DNS » History » Revision 23
Revision 22 (Marc Dequènes, 2020-05-02 08:05) → Revision 23/28 (Marc Dequènes, 2021-02-20 10:41)
{{toc}}
h1. DNS
h2. Zone Management
h3. Adding a Zone
On each DNS server, master zone can be created/updated on _/etc/bind/masters/_. The ownership needs to be:
* _banya:_ if a user zone which should be updatable via the Banya service
* _root:bind_ in all other cases
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 (see the _bind9_ role documentation to understand the parameters). configurations. Only the zone content is not Ansible managed.
h3. Updating a Zone
Edit the file _/etc/bind/masters/<zone-name>.zone_ on the primary master (Orfeo for all zones except DuckLand zones using Elwing).
Do not forget to update the serial!
Better to check the file validity before publishing the zone:
<pre>
named-checkzone <zone-name> <zone-file>
</pre>
Then to publish the zone (DNSSEC-signed zones too):
<pre>
rndc reload <zone-name>
</pre>
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.
h3. Reseting the Zone Serial
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.
h2. Secure Zone Transfers
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.
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.
You can a new key using:
<pre>
dnssec-keygen -a HMAC-SHA512 -b 512 -n HOST taiste
</pre>
Take the 'Key' part in 'Ktaiste.*.private' file, to put into the configuration.
The same playbook (_playbooks/tenants/duckcorp/dns.yml_) is used to update the configuration.
h2. DNSSEC
Here are notes about using Bind KASP (version 9.16 required). 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).
All general info above about DNSSEC does not change, especially expecially the rollover steps are similar even if the tooling change, and testing the zone is identical.
The Ansible _bind_ role has been updated in a branch to be able to use Bind KASP 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.
h3. Introduction
Better read some documentation before fiddling with the controls:
* "Bind DNSSEC Guide":https://downloads.isc.org/isc/dnssec-guide/html/dnssec-guide.html
* "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)
* "Future KSK Rollover Automation":https://www.dns.cam.ac.uk/news/2019-01-30-rollover.html
Key materials are initially created on-demand by Bind using the policy parameters, role when a zone is declared in Ansible, so no need to do anything outside Ansible configuration of the zones and policy parameters. Ansible. Cleanup of old keys when they become obsolete or when a zone is removed is not yet done though.
h3. Notes about migrating from a previous version (historical)
It is important to cleanup old keys first if switching from dnssec-keymgr to dnssec-policy or old keys would get in the way.
More generally look at "this ticket tracking the problems we encountered":https://projects.duckcorp.org/issues/720
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).
h3. Zone Status
General zone info, including the real published serial (after signing, resigning if it happens, rollovers…) and planned signing events:
<pre>
rndc zonestatus <zone-name>
</pre>
h4. Zone Keys
To know which keys (<key-id>) are currently signing a zone (may be inactive and not deleted yet):
<pre>
rndc dnssec -status dig +noall +answer +multi <zone-name> DNSKEY | grep KSK
</pre> (_rndc signing -list <zone-name>_ cannot be used "because of a bug":https://lists.isc.org/pipermail/bind-users/2013-October/091768.html)
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:
<pre>
ls /etc/bind/keys/K<zone-name>.+*+*<key-id>.key
</pre>
Inside you can read the key type (KSK/ZSK) and the lifetime schedule (so important rollover dates).
The KASP _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 in case of bugs but that should not be needed. tool, for example to schedule an emergency rollover if a key is compromised.
In this case, after doing the modifications, Bind needs to be notified notififed using:
<pre>
rndc loadkeys <zone-name>
</pre>
h4. Parent Zone Publishing
To see if the zone KSK keys are properly published in the parent zone:
<pre>
dnssec-checkds <zone-name>
</pre>
(SHA-1 is obsolete, so not published)
h3. Key Rollover
To get a view of the schedule:
<pre>
rndc dnssec -status <zone-name>
</pre>
To have a list of KSK keys that needs publishing on the parent zone:
<pre>
dnssec-checkds <zone-name>
</pre>
The ZSK key rollover is handled automatically by Bind (KASP), (_dnssec-keymgr_ in crontab), so admins have nothing to do.
The KSK rollover implies contact with the parent zone:
* if we do not manage the parent zone:
** 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)
** else and a manual step to get the DS entry in their zone is needed (manually in their UI, maybe via an API)
* if we manage needed. Creating the parent zone:
** if new keys and planning the zone publishes change is also done automatically using the CDS/CDNSKEY RRs (all our zones same tool.
To get a view of the schedule (past events for currently involved keys are displayed too) (beware it is using UTC):
<pre>
dnssec-coverage -K /etc/bind/keys -m 1w -d 1d -k
</pre>
To have them) then we simply need to define the a list of _dnssec_children_ in KSK keys that needs publishing on the parent zone configuration (see bind9 role documentation) and a script will make the update zone:
** else we need to organize with the tenant on a method to exchange the DS <pre>
dnssec-checkds <zone-name>
</pre>
WIPWIPWIP
h3. KSK Rollover Workflow
We use the Double-Signature method with some overlap of DS publishing.
Here are the states and what needs to be done:
* *created* state:
** new created key (new zone or key replacement), this key is not used yet
** action: wait
* *publish* state:
** the is added to the zone but not used to sign yet
** after the zone default TTL has passed, it is considered published
** action: wait for propagation
* *active* state:
** the key is used for signing
** action: export the key either (depending on the registrar):
*** 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)
*** 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)
** action: add the key to the parent zone
** after the DS TTL has passed, it is considered published and the zone is secured with the key
** action: wait for the next rollover
* *inactive* state:
** the key is no more used to sign but still published
** action: remove the DS key from the parent zone
* *deleted* state:
** the key is not published anymore
** action: when you're sure everything went fine, purge old keys (should be automated some day)
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 plan in the long run is to use CDS/CDNSKEY (RFC 7344). Some interesting reading about an implementation:
https://jpmens.net/2017/09/21/parents-children-cds-cdnskey-records-and-dnssec-cds/
h3. Checking a Zone
Test a Zone using a DNSSEC-enabled resolver:
<pre>
dig <zone-name> +dnssec
</pre>
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).
Test a Zone using an external web tool:
* http://dnssec-debugger.verisignlabs.com/
* http://dnsviz.net/
h3. Forcing a policy change to be applied at once
Via Ansible it is possible to change the policy directly and Bind should trigger the changes automagically. Currently we have not tested directly, then either wait 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. few hours or run _dnssec-keymgr_ manually (as _bind_ user).
h3. Unsecuring a Zone
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 unsigning.
The Ansible config can then 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.
updated. Key materials need to be removed manually.
h3. Forcing an Early Rollover
It is possible to do so: https://blog.webernetz.net/dnssec-ksk-emergency-rollover/
You can trigger an immediate change of Summary:
* create new key: *dnssec-keygen -a RSASHA512 -b 4096 -3 -f KSK (with <key-id> <zone-name>* (in _/etc/bind/keys_ and ensuring proper permissions for Bind)
* resign the ID of zone: *rndc sign <zone-name>*
* publish the key you wish to replace): in the parent zone (see KSK Rollover Workflow above)
<pre>
rndc dnssec -rollover -key <key-id> <zone-name>
</pre>
There * 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 currently a bug so it may take up to a week to trigger.
24h for Gandi)
h2. Checking Servers
* "ISC EDNS Compliance Tester":https://ednscomp.isc.org/ednscomp/
h3. DNSSEC Checks
Should return a A record and have the *ad* flag set:
<pre>
dig sigok.verteiltesysteme.net @127.0.0.1
</pre>
Should return *SERVFAIL*:
<pre>
dig sigfail.verteiltesysteme.net @127.0.0.1
</pre>
h2. Problems
h3. receive_secure_serial: not exact
This means the inline-signing journal is corrupted and changes to the zone cannot be applied to the signed zoned.
Workaround:
<pre>
rndc sync -clean <zone>
rndc stop
</pre>
then bump the zone's serial and restart Bind, it should have solved the problem.
If this does not work:
<pre>
systemctl stop bind9
rm /var/cache/bind/masters/<zone>.zone.*
systemctl start bind9
</pre>