Project

General

Profile

DNS » History » Revision 3

Revision 2 (Marc Dequènes, 2018-05-04 15:24) → Revision 3/28 (Marc Dequènes, 2018-05-04 16:40)

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: add the key to the parent zone (to get the key: *ods-enforcer key export -z <zone-name> --keytype KSK --keystate ready*) 
 ** 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)*) 

 TODO