Refactored RPZ has a scalability design problem
(Don't let that title sound discouraging - IMO it is still better than the old RPZ code, but more work is necessary.)
Last week I heard from a provider of feed data that they need resolvers to react quickly and the current 60s default update rate plus the fact that RPZ does a full iteration of the DB will not work for them as their data is not latency tolerant and their policy zones are large.
There was a separate bug ticket by a popular reporter from another ISC customer in the last 1-2 months that asked whether this 60s update time could be improved to match the old RPZ behavior.
I feel this can be addressed. BIND RPZ would need to hook not just into
dns_db_updatenotify_register(), but also into a
newdbversion signal and every
del update to the DB. Note that the RPZ view summary datastructure is still not versioned, so RPZ code would have to separately batch and keep aside a copy of the update diffs until the DB version commit passes, and then apply just the diffs to the RPZ view summary data structure instead of iterating the zone. I think versioning the view summary datastructure would be too much work and complicate the structure.. as long as the diff is applied to it after the DB version commit passes, there should be no problem of inconsistent data.