nsd icon indicating copy to clipboard operation
nsd copied to clipboard

Uncleanly closed recreated database does not force transfer all secondary zones or report the true zone status

Open nomis opened this issue 5 years ago • 3 comments

nsd is abandoning its database and starting with an empty database:

2020-09-03T12:41:53.918+01:00 nsd[1601]: /var/lib/nsd/nsd.db: not cleanly closed 0
2020-09-03T12:41:53.927+01:00 nsd[1601]: can not use /var/lib/nsd/nsd.db, will create anew
2020-09-03T12:41:55.473+01:00 nsd[1601]: nsd started (NSD 4.1.17), pid 1571

It doesn't retransfer any zones (and is using potentially out of date copies of zones that have been committed to files).

The zone status is "ok" but all queries return SERVFAIL.

  • [ ] This must report the real state of the zone. If it's returning SERVFAIL for any reason it can't be considered "ok".
# nsd-control zonestatus uuid.uk
zone:	uuid.uk
	state: ok
	served-serial: "1598993412 since 2020-09-02T06:22:12"
	commit-serial: none

Restarting nsd causes the missing zone content to be transferred again:

  • [ ] This should have happened automatically.
# nsd-control zonestatus uuid.uk
zone:	uuid.uk
	state: ok
	served-serial: "1599129634 since 2020-09-03T13:02:55"
	commit-serial: "1599129634 since 2020-09-03T13:02:55"

There is no zonefile configured for this zone.

It looks like nsd is using the content of /var/lib/nsd/xfrd.state to decide not to transfer any zones on startup, ignoring that /var/lib/nsd/nsd.db is then unusable.

The primary server could be unavailable, so it would be better if nsd didn't delete all its secondary zone data.

  • [ ] Recreated database should attempt to reuse any intact zones

nomis avatar Sep 03 '20 12:09 nomis

I've made a PR to raise the log level of the recreated database message, because warning is not enough: https://github.com/NLnetLabs/nsd/pull/121

nomis avatar Sep 03 '20 12:09 nomis

I think you should try to upgrade, it looks like perhaps the fix for eg. #25 could be relevant. 4.1 is a long time ago.

Apart from that we advise people to run with database: "" setting. Then there is no database. If needed, associate a zonefile with the zone, the data is then written to the zonefile once in a while after it has updated. If you do not set a zonefile, or set "", then the zone is kept in memory and updated from there.

With the database: "" if one zonefile does not work, it should pick up the other ones that work and transfer the missing zones.

wcawijngaards avatar Sep 03 '20 12:09 wcawijngaards

I will try migrating to using zone files instead of the database.

Even the latest version of nsd only uses the xfrd state information for the zonestatus command, when I'd really like to know if any zone is returning SERVFAIL without having to query all of the zones via DNS.

nomis avatar Sep 03 '20 13:09 nomis