rec: Is not allowing empty forward lists too strict?

[omoerbeek]

YAML code already disallowed empty forwarders list, #15194 (not in a release yet) disallowed that for old-style.

But #15295 has an example of an admin using an empty forwarders list as a quick way to blacklist a zone. master won't allow this, on 5.2.0 this results in:

Mar 14 07:40:38 msg="Question" subsystem="syncres" level="0" prio="Info" tid="2" ts="1741934438.091" ecs="" mtid="1" proto="udp" qname="1cent.in" qtype="A" remote="127.0.0.1:57738"
Mar 14 07:40:38 [1] 1cent.in: Wants DNSSEC processing, auth data required by query for A
Mar 14 07:40:38 [1] 1cent.in: No cache hit for '1cent.in|A', trying to find an appropriate NS record
Mar 14 07:40:38 [1] 1cent.in: Cache consultations done, have 1 NS to contact
Mar 14 07:40:38 [1] 1cent.in: Domain is out-of-band
Mar 14 07:40:38 [1] 1cent.in: Auth storage has data, zone='1cent.in'
Mar 14 07:40:38 [1] 1cent.in: Determining status after receiving this packet
Mar 14 07:40:38 [1] 1cent.in: Status=NXDOMAIN, we are done 
Mar 14 07:40:38 [1] 1cent.in: Validation state was Indeterminate, state update is Indeterminate, validation state is now Indeterminate
Mar 14 07:40:38 [1] 1cent.in: Failed (res=3)
Mar 14 07:40:38 msg="Answer" subsystem="syncres" level="0" prio="Info" tid="2" ts="1741934438.091" additional="1" answer-is-variable="0" answers="0" dotout="0" ecs="" into-packetcache="1" maxdepth="0" mtid="1" netms="0.000000" outqueries="0" proto="udp" qname="1cent.in" qtype="A" rcode="3" rd="1" remote="127.0.0.1:57738" tcpout="0" throttled="0" timeouts="0" totms="0.000000" validationState="Indeterminate"

[rgacogne]

Personally I don't like the "hack" very much, because the semantics of what happens in that case are not clear, but it's probably a good indication of a missing feature in the recursor. Would it make sense to add a setting listing zones that are denied?

[CBbIH9I]

Personally I don't like the "hack" very much, because the semantics of what happens in that case are not clear, but it's probably a good indication of a missing feature in the recursor. Would it make sense to add a setting listing zones that are denied?

I don't like it either, it was a quick and dirty hack to implement "blacklist" feature somehow, so yes, it was just a matter of time when this will either stop working or break something. Having "blacklist" feature implementation would be awesome in times like these.

[omoerbeek]

We already have two ways to blacklist: RPZs and Lua. I'm wondering if we really need a third way...

[rgacogne]

That's a very good point. My feeling is that setting up a RPZ zone is a bit involved, and using Lua is great when you want something dynamic but feels a bit weird for denying a couple domains, especially if you are deploying via Ansible, PowerDNS Cloud Control or something like that.

[omoerbeek]

If we're going for an easy way to specify a blocklist, internally it will be an RPZ, I think

[CBbIH9I]

We already have two ways to blacklist: RPZs and Lua. I'm wondering if we really need a third way...

Honestly, I'm not sure. I mean, if my case is not something that has high demand as a feature, why bother with implementation of the feature that nobody requested :)

[omoerbeek]

We already have two ways to blacklist: RPZs and Lua. I'm wondering if we really need a third way...

Honestly, I'm not sure. I mean, if my case is not something that has high demand as a feature, why bother with implementation of the feature that nobody requested :)

Like suggested above, if we're going to add an easy way to blacklist taking just a list of names, internally it wil be an RPZ. We would add syntactic sugar code to turn the simple list it into a regular RPZ.