I would like to feed the zonestatus of our slave-domains into our
monitoring.
# nsd-control zonestatus
zone: at
state: ok
served-serial: "1513598401 since 2017-12-18T12:53:44"
commit-serial: "1513663202 since 2017-12-19T06:06:09"
zone: versicherung
state: ok
served-serial: "1513605664 since 2017-12-18T14:01:08"
commit-serial: "1513670464 since 2017-12-19T08:01:10"
...
Are there tools available to parse the output?
Is it possible to get a more structured output (csv, json ...)?
The man page states: The state of the zone is printed as: 'master'
(master zones), 'ok' (slave zone is up-to-date), 'expired' (slave zone
has expired), 'refreshing' (slave zone has transfers active).
Is it possible to detect refresh or axfr errors, e.g. the SOA
refresh-query to the master failed or the SOA query suceeded but the XFR
failed? I would like to detect errors before the status switches to expired.
Is it possible to detect refresh or axfr errors, e.g. the SOA
refresh-query to the master failed or the SOA query suceeded but the XFR
failed? I would like to detect errors before the status switches to expired.
What you're asking for is essentially the last log entry for this zone.
It might actually be a good idea, assuming NSD is keeping (or can keep)
that data in memory to be able to print out.
A small observation is that NSD doesn't do separate SOA queries before
an XFR. It immediately attempts an XFR over TCP. It looks at the first
packet for the SOA record, and if the serial number is the same, it
abandons the XFR. If the master's serial is higher is completes the XFR.
# nsd-control zonestatus
zone: at
state: ok
served-serial: "2018011732 since 2018-01-17T15:23:57"
commit-serial: "2018011732 since 2018-01-17T15:23:57"
# nsd-control force_transfer at
ok
# nsd-control zonestatus
zone: at
state: refreshing
served-serial: none
commit-serial: none
notified-serial: "0 since 2018-01-17T15:34:17"
transfer: "TCP connected to 83.136.34.20"
IS this correct behavior? It is confusing that, during the transfer the
served-serial and commit-serial is "none".
Yes this is correct behaviour, it is to make the force_transfer accept
any serial number (even with AXFR, and even the same serial number), by
wiping it away from the status. The most recent serial is still being
served from the DNS port 53, but the status of that is removed to make
NSD accept the same serial again.
Normal transfer, 'nsd-control transfer', doesn't need to wipe that
status, and should show the values you were looking for in the
zonestatus output. The transfer command is also faster: if the serial
number has not changed it'll conclude no transfer is needed, and it can
use IXFR to download only the differences.