NLnetLabs / nsd

The NLnet Labs Name Server Daemon (NSD) is an authoritative, RFC compliant DNS nameserver.
https://nlnetlabs.nl/nsd
BSD 3-Clause "New" or "Revised" License
444 stars 101 forks source link

Doesn't reload zone when included files change #57

Open madduck opened 4 years ago

madduck commented 4 years ago

When I make a change to a file $INCLUDEd in a zone file, nsd cowardly refuses to reload the zone, claiming that the zone file hasn't been modified on disk. It hasn't, but nsd should be checking included files as well, and reload if any files in the include tree have been modified.

and0x000 commented 4 years ago

~Do you probably look for the reconfig command? From my understanding, NSD differentiates between zone configuration and zone data.~

~zone configuration needs the reconfig, zone data the reload command in nsd-control.~

~I use some heavy file inclusion in a setup of mine. When a zone, that is included as a file changes (e.g. gets new configuration for AXFR), I submit a reconfig via nsd-control to make NSD recognize these changes. When the zone file for a primary zone changes, I use the reload command. Works like a charm.~

Edit: Cancel that, I misunderstood the issue and thought about including via config file, not about the $INCLUDE directive in bind style zonefiles.

wcawijngaards commented 4 years ago

Yes! That's it. reconfig sounds like it is the ticket. The other command only checks the file modification times of the zone file itself.

wcawijngaards commented 4 years ago

Actually I made a mistake to close it because the answer is for config files, not zone files.

k0ekk0ek commented 3 weeks ago

@wcawijngaards, @wtoorop, is this something we want to implement? We'd need to do dependency checking for zones. I'm thinking this could be implemented via a callback in simdzone when an $INCLUDE is closed and in namedb_check_zonefile we then simply check the mtime for all files in the list? (@madduck, that would alleviate the need for a force-reload, right?)

madduck commented 3 weeks ago

@k0ekk0ek that sounds like the ticket, and what you suggests with callbacks makes it rather elegant, at least if I picture this right.

The other approach of course might be to simply recompile the zone using the standard path honouring $INCLUDE and compare the checksum & size of the result with what has been loaded previously, and to only reload if there's a difference.

Then again: how would it actually hurt if the zone was just reloaded, even if unchanged?

wcawijngaards commented 3 weeks ago

Yes, I think a callback and checking all files in the list for modification is a good approach. That feature is useful, to reload zones if the included files change. The mtime check is useful, because some set ups have large zone files. It is then useful to only reload the zone files that have changed, instead of everything.

k0ekk0ek commented 3 weeks ago

Fixed once PR #377 is merged.