Doesn't reload zone when included files change

[madduck]

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]

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]

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]

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

[k0ekk0ek]

@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]

@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]

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]

Fixed once PR #377 is merged.