Verified Commit 722806d6 authored by anarcat's avatar anarcat
Browse files

two DNS nagios issues i found today

parent e0374359
Loading
Loading
Loading
Loading
+60 −0
Original line number Diff line number Diff line
@@ -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
@@ -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/)