Loading howto/dns.md +60 −0 Original line number Diff line number Diff line Loading @@ -43,6 +43,10 @@ must be followed: 6. add zone to nagios: copy an existing `DNS SOA sync` block and adapt 7. add zone to external DNS secondaries (currently [Netnod](https://www.netnod.se/)) 8. make sure the zone is delegated by the root servers somehow. for normal zones, this involves adding our nameservers in the registrar's configuration. for reverse DNS, this involves asking our upstreams to delegate the zone to our DNS servers. Note that this is a somewhat rarer procedure: this happens only when a completely new [domain name](https://en.wikipedia.org/wiki/Domain_name) (e.g. `torproject.net`) or IP address Loading Loading @@ -166,6 +170,62 @@ and re-running Puppet: rm /var/lib/unbound/30.172.in-addr.arpa.key ; puppet agent -t ## Pager playbook ### DNS - zones signed properly is CRITICAL When adding a new reverse DNS zone, it's possible you get this warning from Nagios: 13:31:35 <nsa> tor-nagios: [global] DNS - zones signed properly is CRITICAL: CRITICAL: 82.229.38.in-addr.arpa 16:30:36 <nsa> tor-nagios: [global] DNS - key coverage is CRITICAL: CRITICAL: 82.229.38.in-addr.arpa That might be because Nagios thinks this zone should be signed (while it isn't and cannot). The fix is to add this line to the zonefile: ; ds-in-parent = no And push the change. Nagios should notice and stop caring about the zone. In general, this Nagios check provides a good idea of the DNSSEC chain of a zone: $ /usr/lib/nagios/plugins/dsa-check-dnssec-delegation overview 82.229.38.in-addr.arpa zone DNSKEY DS@parent DLV dnssec@parent --------------------------- -------------------- --------------- --- ---------- 82.229.38.in-addr.arpa no(229.38.in-addr.arpa), no(38.in-addr.arpa), yes(in-addr.arpa), yes(arpa), yes(.) Notice how the `38.in-addr.arpa` zone is not signed? This zone can therefore not be signed with DNSSEC. ### DNS - delegation and signature expiry is WARNING If you get a warning like this: 13:30:15 <nsa> tor-nagios: [global] DNS - delegation and signature expiry is WARNING: WARN: 1: 82.229.38.in-addr.arpa: OK: 12: unsigned: 0 It might be that the zone is not delegated by upstream. To confirm, run this command on the Nagios server: $ /usr/lib/nagios/plugins/dsa-check-zone-rrsig-expiration 82.229.38.in-addr.arpa ZONE WARNING: No RRSIGs found; (0.66s) |time=0.664444s;;;0.000000 On the primary DNS server, you should be able to confirm the zone is signed: dig @nevii -b 127.0.0.1 82.229.38.in-addr.arpa +dnssec Check the next DNS server up (use `dig -t NS` to find it) and see if the zone is delegated: dig @ns1.cymru.com 82.229.38.in-addr.arpa +dnssec If it's not delegated, it's because you forgot step 8 in the zone addition procedure. Ask your upstream or registrar to delegate the zone and run the checks again. # Design This needs to be documented better. weasel made a [blog post](https://dsa.debian.org/dsablog/2014/The_Debian_DNS_universe/) Loading Loading
howto/dns.md +60 −0 Original line number Diff line number Diff line Loading @@ -43,6 +43,10 @@ must be followed: 6. add zone to nagios: copy an existing `DNS SOA sync` block and adapt 7. add zone to external DNS secondaries (currently [Netnod](https://www.netnod.se/)) 8. make sure the zone is delegated by the root servers somehow. for normal zones, this involves adding our nameservers in the registrar's configuration. for reverse DNS, this involves asking our upstreams to delegate the zone to our DNS servers. Note that this is a somewhat rarer procedure: this happens only when a completely new [domain name](https://en.wikipedia.org/wiki/Domain_name) (e.g. `torproject.net`) or IP address Loading Loading @@ -166,6 +170,62 @@ and re-running Puppet: rm /var/lib/unbound/30.172.in-addr.arpa.key ; puppet agent -t ## Pager playbook ### DNS - zones signed properly is CRITICAL When adding a new reverse DNS zone, it's possible you get this warning from Nagios: 13:31:35 <nsa> tor-nagios: [global] DNS - zones signed properly is CRITICAL: CRITICAL: 82.229.38.in-addr.arpa 16:30:36 <nsa> tor-nagios: [global] DNS - key coverage is CRITICAL: CRITICAL: 82.229.38.in-addr.arpa That might be because Nagios thinks this zone should be signed (while it isn't and cannot). The fix is to add this line to the zonefile: ; ds-in-parent = no And push the change. Nagios should notice and stop caring about the zone. In general, this Nagios check provides a good idea of the DNSSEC chain of a zone: $ /usr/lib/nagios/plugins/dsa-check-dnssec-delegation overview 82.229.38.in-addr.arpa zone DNSKEY DS@parent DLV dnssec@parent --------------------------- -------------------- --------------- --- ---------- 82.229.38.in-addr.arpa no(229.38.in-addr.arpa), no(38.in-addr.arpa), yes(in-addr.arpa), yes(arpa), yes(.) Notice how the `38.in-addr.arpa` zone is not signed? This zone can therefore not be signed with DNSSEC. ### DNS - delegation and signature expiry is WARNING If you get a warning like this: 13:30:15 <nsa> tor-nagios: [global] DNS - delegation and signature expiry is WARNING: WARN: 1: 82.229.38.in-addr.arpa: OK: 12: unsigned: 0 It might be that the zone is not delegated by upstream. To confirm, run this command on the Nagios server: $ /usr/lib/nagios/plugins/dsa-check-zone-rrsig-expiration 82.229.38.in-addr.arpa ZONE WARNING: No RRSIGs found; (0.66s) |time=0.664444s;;;0.000000 On the primary DNS server, you should be able to confirm the zone is signed: dig @nevii -b 127.0.0.1 82.229.38.in-addr.arpa +dnssec Check the next DNS server up (use `dig -t NS` to find it) and see if the zone is delegated: dig @ns1.cymru.com 82.229.38.in-addr.arpa +dnssec If it's not delegated, it's because you forgot step 8 in the zone addition procedure. Ask your upstream or registrar to delegate the zone and run the checks again. # Design This needs to be documented better. weasel made a [blog post](https://dsa.debian.org/dsablog/2014/The_Debian_DNS_universe/) Loading