DuckCorp » DuckCorp Infrastructure

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 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*)

TODO