I'm personally weary of software that tries to do IP-level allow/deny, because it's effort spent on a feature that either is rarely used (ie most users' threat model presume the LAN is safe) or it would get heavily used and its performance becomes a limiting factor (eg WAN exposed service). There isn't really much of an in-between here, and so I generally ignore such features and would use a proper software firewall to reject at the network level. A firewall can also do rate limiting, and other things like permitting blocked IPs to have another go after a cool-down time.
But supposing you still want to proceed, what you've described would cover the simplest case, yes. But consider that firewall rules often allow you to have ordered rules, such as: block by default, but allow anyone from 2001:db8::/32, but reject from 2001:db8:69::/64, except that 2001:db8:69::420/128 is cool and should be allowed. Here, that would be four rules for a firewall like Linux nftables or FreeBSD pf.
In your case, how many entries would it take to convey the same intent, where there are "enclaves" to the allowlist? This is the sort of complexity that firewalls have already solved, and if it's a matter of integrating a dynamic block feature into your app, you could just have your app tie into the OS firewall. Any firewall worth its salt will have APIs to do that, such as pf's in-memory "tables" that are a list of all IPs that are grouped together to apply a rule. These are expressly designed to be added to/remove from frequently and efficiently. The rule doesn't change, but the table of IPs affected would be updated by your app.