"recurse_zones" for cancelling more specific part (subdomain) of "forward_zones"

[g0tar]

• Program: Recursor
• Issue type: Feature request

Short description

Among other settings (mostly RPZs) I got forward_zones_recurse directing everything to other resolver:

    forward_zones_recurse:
    - zone: .
      forwarders:
      - A.B.C.D

Now, however, I'd like to undo this forwarding for specific (sub)domains and made them resolve using "natural" recursive way by itself, i.e. using root hints and following down the path. I'm struggling to find any option that could make that possible.

Usecase

The A.B.C.D upstream resolver is external filtering service. I want to not use it's filtering capabilities for some domains (and save it some queries at the same time). The domains I don't want to filter are not mine, therefore I don't control their authoritative servers - they need to be queried based on "classic" resolution mechanisms (NS records etc.). The closest I could think of was:

    forward_zones_recurse:
    - zone: .
      forwarders:
      - A.B.C.D
   - zone: net.pl
     recurse: true
     forwarders:
     - f.root-servers.net.
     - e.root-servers.net.
     - d.root-servers.net.
     - j.root-servers.net.

    system_resolver_ttl: 3600

but this obviously doesn't work as recursor expects root-server to return final answer (the recurse flag AFAIK only sets the RA flag, doesn't switch entire stanza to recursive). I also tried using empty forwarders but such configuration is forbidden.

As an extra this could enable QName minimization for such sub-zone, which is not used during forwarding.

Can I make such exception from zone: . directly?
in-addr.arpa. is another example of zone that could be opted-out from forwarding (back to recursion).

I know I can run separate recursor and use it as forwarder from the master, but this seems an overkill and I'd like to avoid running more instances only for this scenario.

[omoerbeek]

You can setup more than one forwarder. One is filtering, and is a regular recursor (or a public recursive service like quad9).

forward_zones_recurse:
    - zone: .
      forwarders:
      - ip_of_filtering_recursor
   - zone: exception.net:
     forwarders: 
     - ip_of_non_filtering recursor

This recursor then does not do much else than forwarding (and caching), so a similar config can be setup using dnsdist forwarding to two (sets of) recursors.

Moving this to a discussion, as I don't think the feature is very useful in the recursor and it would add substantial complexity to already quite complex code.

[g0tar]

First of all I wanted to be sure I'm not missing something obvious or undocumented (i.e. possibility for the forwarded zone to be not forwarded, but recursed). Also, it might have been an easy case to handle (as a FR), but as you say it's complex to code then it's fair enough for me.
Apparently I need to set dnsdist up in order to load-balance forwarders anyway, so I'll end up with dnsdist -> {RPZ recursor and failovers} -> {dnsdist balancer for filtering forwarders and recursor for not-filtered zones}:

dnsdist -+- recursor (RPZs)
         |  |- recursor (using root hints)
         |  \- dnsdist (balancing)
         |     |-filtering forwarder #1 
         |     \-filtering forwarder #2
         \- failover

[omoerbeek]

I'm note sure why you would need two dnsdist instances. Can you eloborate on that?

[g0tar]

First one (the leftmost) to provide failover in case when recursor would become unavailable (power outages etc.). It would sit directly on or close to BNG/BRAS and the backup services are external (so should be used only when primary recursor is down).
Second dnsdist to load-balance recursor's forwarders (as recursor doesn't balance traffic itself, just selects currently best and uses it exclusively for a moment, per zone, I'd prefer to have them used concurrently).
The recursor between is required for RPZs (legal requirement).

AFAIK these functions are exclusive to these subprojects, therefore I need to daisy chain them. Or am I missing something?

Edit: one more to explain is that top-level backup services are not the same as bottom-one forwarders, the former ones already include mandatory RPZ, but have no additional filtering of latters.