[FR] modify behaviour of unbound-control rpz_enable zone (or ...)

[jpgpi250]

unbound-control can disable / enable a zone (syntax, example zone doh: sudo /usr/sbin/unbound-control rpz_enable doh

The doh zone has the following `header:

$TTL 30
@ SOA jpgpi250.github.io. hostmaster.jpgpi250.github.io. 2205150849 86400 1800 604800 30
NS localhost.

which implies, if I'm not wrong, unbound will fetch the latest version once a day. This time frame (24h) will start when unbound starts and fetches the zone.

The script that generates the zone runs once a day, if however unbound is (re)started shortly before the new data becomes available, unbound uses the old data for almost a day.

It would be very usefull to change the behaviour of unbound-control rpz_enable ( or, see below), so that the zone file would be refreshed immediatly, once the zone is enabled. This would allow for:

• generate new zone file (script, that has nothing to do with unbound)
• disable the rpz zone (sudo /usr/sbin/unbound-control rpz_disable doh)
• enable the rpz zone (sudo /usr/sbin/unbound-control rpz_enable doh), and thus fetch the latest zone data.

of course, I'm not opossed to an additional (new) unbound-control command: unbound-control rpz-refresh zone ...

for now, I'm forced to restart unbound to force an update, as unbound-control reload doesn't appear to force a refresh (fetch the latest zone dat from source).

[gthess]

Hello there,
I wouldn't like for the enable action to have implicit results i.e., transferring the zone.
Since RPZ zones share the same behavior as auth zones in Unbound, there is already the command unbound-control auth_zone_transfer that could be used to initiate a new transfer from master for a configured zone (auth or RPZ).
I believe this is exactly what you are asking.
I will update the unbound-control documentation to reflect that.

[jpgpi250]

tested, correct, sudo /usr/sbin/unbound-control auth_zone_transfer "doh" works as desired.

Thanks for your time and effort.