DNS » History » Revision 4
Revision 3 (Marc Dequènes, 2018-05-04 16:40) → Revision 4/28 (Marc Dequènes, 2018-05-04 16:54)
h1. DNS h2. 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: <pre> named-checkzone <zone-name> <zone-file> </pre> Then to update the zone, if DNSSEC-signed: <pre> ods-signer sign <zone-name> </pre> else: <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. 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 h3. Introduction Better read some documentation before fiddling with the controls: * "Supported rollover methods with OpenDNSSEC":https://wiki.opendnssec.org/display/DOCS/Key+Rollovers * "Explanation about the OpenDNSSEC key states":https://wiki.opendnssec.org/display/DOCS/Key+States * "Deeper explanation about the OpenDNSSEC key states":https://wiki.opendnssec.org/display/DOCS20/Key+States+Explained List of keys with states and IDs: <pre> ods-enforcer key list -v </pre> List of planned rollover dates: <pre> ods-enforcer rollover list </pre> h3. Key Rollover 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. h3. 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 add the key, either using key to the DNSKEY or DS format depending on parent zone (to get the provider (*ods-enforcer key: *ods-enforcer key export -z <zone-name> --keytype KSK --keystate ready* for the DNSKEY, or add *--ds* for the DS) ready*) ** 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*) TODO