omoerbeek
commented
5 days ago reload-lua-config should not reload the full RPZs defined by rpzPrimary (only a SOA check should be triggered followed by a partial IXFR if the other side offers that), but maybe a bug crept in.
I'll try to reproduce. For that I need to know which version of the recursor you are running.
Update: my memory was wrong: I do see a full reload. But if you define a dumpFile and seedFile (of the same name), a reload will be done using the file and then an IXFR request will be done to get updates.
Nov 20 11:13:52 msg="Received rec_control command via control socket" subsystem="control" level="0" prio="Info" tid="0" ts="1732097632.810" command="reload-lua-config"
Nov 20 11:13:52 msg="Processing main YAML settings" level="0" prio="Notice" tid="0" ts="1732097632.810" path="./recursor.yml"
Nov 20 11:13:52 msg="YAML config found and processed" level="0" prio="Notice" tid="0" ts="1732097632.810" configname="./recursor.yml"
Nov 20 11:13:52 msg="Processing YAML settings" level="0" prio="Notice" tid="0" ts="1732097632.810" path="tmp/api-dir/allow-from.yml"
Nov 20 11:13:52 msg="Pre-loading RPZ zone from seed file" level="0" prio="Info" tid="0" ts="1732097632.826" seedfile="tmp/rpz.dump" zone="rpz.local"
Nov 20 11:13:52 msg="Getting IXFR deltas" subsystem="rpz" level="0" prio="Info" tid="0" ts="1732097632.957" address="192.168.178.3:1533" ourserial="2024111401" zone="rpz.local"
Nov 20 11:14:30 msg="A more recent configuration has been found, stopping the existing RPZ update thread" subsystem="rpz" level="0" prio="Info" tid="0" ts="1732097670.528" zone="rpz.local"
Nov 20 11:14:52 msg="Getting IXFR deltas" subsystem="rpz" level="0" prio="Info" tid="0" ts="1732097692.964" address="192.168.178.3:1533" ourserial="2024111401" zone="rpz.local"
Nov 20 11:15:52 msg="Getting IXFR deltas" subsystem="rpz" level="0" prio="Info" tid="0" ts="1732097752.972" address="192.168.178.3:1533" ourserial="2024111401" zone="rpz.local"
Nov 20 11:16:52 msg="Getting IXFR deltas" subsystem="rpz" level="0" prio="Info" tid="0" ts="1732097812.980" address="192.168.178.3:1533" ourserial="2024111401" zone="rpz.local"
g0tar
Short description
Apparently Recursor lacks the command to notify about RPZ file update.
reload-lua-configis all-or-nothing and triggers also IXFR "whole zone" transfers for rpzPrimary() RPZ (why is this happening anyway?) which might be multi-megabytes in size, therefore not suitable for frequent updates.Usecase
I use 3 rpzPrimary() and 2 rpzFile() sources. The DNS-based ones support IXFR, so I don't need to worry about updates, but RPZ files are cyclically fetched from remote servers (possibly with different frequency) and I need to notify recursor to grab new ones.
Description
I'm looking for a way to frequently update RPZ files without refetching entire rpzPrimary(). These zones can be large, so it would be best if this was possible on file-by-file basis, but as local storage is fast enough it might as well trigger all of them at all (with regard to CPU intensiveness of recursor itself, reloading needlessly files that didn't change). I don't want to saturate RPZ-over-DNS providers though by issuing "whole zone" transfers every few minutes.
I thought that maybe
reload-zoneswould work (after reading https://github.com/PowerDNS/pdns/issues/11490#issuecomment-2134915428), but it's not. Maybe this command could gain some switch for RPZ (reload-zones -rpz)?As an alternative there could be some new
rec_controlcommand to load/unload specified RPZ file without invoking entire LUA config, or some inotify watch installed for reload to happen automagically.Or maybe simply some way to suppress "whole zone" transfers after
reload-lua-config?Currently I'm thinking about file-to-authoritative substitute approach, where RPZ files are handled by separate pdns, which then is used as rpzPrimary() on the main recursor, but this seems a bit too much work for what it's worth.