Zone Management¶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. Only the zone content is not Ansible managed.
Better to check the file validity before updating the zone:
named-checkzone <zone-name> <zone-file>
Then to update the zone, if DNSSEC-signed:
ods-signer sign <zone-name>
rndc reload <zone-name>
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.
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:
dnssec-keygen -a HMAC-SHA512 -b 512 -n HOST taiste
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.
Introduction¶Better read some documentation before fiddling with the controls:
- Supported rollover methods with OpenDNSSEC
- Explanation about the OpenDNSSEC key states
- Deeper explanation about the OpenDNSSEC key states
List of keys with states and IDs:
ods-enforcer key list -v
List of planned rollover dates:
ods-enforcer rollover list
The ZSK key rollover is handled automatically by OpenDNSSEC, so admins have nothing to do.
The KSK rollover implies contact with the parent zone and a manual step to get the DS entry in their zone is needed.
KSK Rollover Workflow¶Here are the states and what needs to be done:
- publish state:
- 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
- action: wait
- ready state:
- the new zone, containing the key, is considered propagated, but not used to sign yet
- 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)
- action: add the key to the parent zone
- 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))
- action: notify OpenDNSSEC (ods-enforcer key ds-seen -z <zone-name> --cka_id <key-id>)
- active state:
- the key is used for signing
- action: wait for the next rollover
- retire state:
- the key is no more used to sign but still advertized
- action: remove the key from the parent zone
- action: wait for the key to disappear from the parent zone (host -t DS -r <zone-name> $(host -t NS <tld> | grep "name server" | head -n 1 | cut -d" " -f4))
- action: notify OpenDNSSEC (ods-enforcer key ds-gone -z <zone-name> --cka_id <key-id>)
- action: purge old keys (ods-enforcer key purge --policy default)