Option to fallback to next Forwarder on NXDOMAIN response (Ignore NXDOMAIN)

[SKProCH]

I am facing a complex Split-Horizon DNS scenario where I have multiple VPN connections and network interfaces.
I have a specific setup in <root> with:

1. General Internet Forwarder (e.g., Router/ISP) with Priority: 100.
2. Private VPN Forwarders (e.g., Corporate DNS) with Priority: 110, 120, etc.

Currently, when I query a private domain (e.g., internal.corp), Technitium sends the request to the General Forwarder (Priority 100). The General Forwarder does not know about this domain and returns NXDOMAIN.
Technitium accepts this NXDOMAIN as the final answer and stops processing, so the Private Forwarders (Priority 110+) are never queried.

Describe the solution you'd like
I would like to request an option (a checkbox in the FWD record settings or a global "Forwarding Strategy" setting) to ignore NXDOMAIN responses and continue trying the next forwarder in the priority list.

Logic flow:

1. Query sent to Forwarder A (Priority 100).
2. Forwarder A returns NXDOMAIN.
3. If "Ignore NXDOMAIN" is enabled: The server disregards the response and tries Forwarder B (Priority 110).
4. Forwarder B returns the A Record.
5. Server returns the valid IP to the client.

Describe alternatives you've considered

1. Conditional Forwarding Zones: This is the standard solution. However, I have a large number of dynamic internal domains across different VPNs. Creating and maintaining a separate Forwarder Zone for every single internal domain is difficult and inefficient in my environment.
2. Changing Priorities: Making the Private DNS the primary forwarder (Priority 0) is not ideal because I do not want to send all my public internet traffic through the private VPN DNS for privacy and performance reasons.
3. Probably I'm missing the right way to do it?

Additional context
This feature is similar to the "strict-order" logic combined with specific fallback behavior found in some other DNS forwarders (like dnsmasq with specific configurations). I understand this might technically violate standard DNS RFCs (where NXDOMAIN is authoritative), but it is extremely useful for client-side split-tunneling scenarios where we cannot easily enumerate all upstream zones.

[ShreyasZare]

Thanks for the request. Have you considered using the Advanced Forwarding app where you can configure one or more internal zones in an array in the config and get them forwarded to the specified upstream? Does this work for your scenario?

[SKProCH]

I'll tried to use that plugin, but with no luck actually. I have the following config:

{
  "appPreference": 200,
  "enableForwarding": true,
  "proxyServers": [],
  "forwarders": [
    {
      "name": "internal-vpn",
      "proxy": null,
      "dnssecValidation": false,
      "forwarderProtocol": "Udp",
      "forwarderAddresses": [
        "10.10.10.10",
        "10.11.7.10"
      ]
    }
  ],
  "networkGroupMap": {
    "0.0.0.0/0": "everyone",
    "[::]/0": "everyone"
  },
  "groups": [
    {
      "name": "everyone",
      "enableForwarding": true,
      "forwardings": [
        {
          "forwarders": [
            "internal-vpn"
          ],
          "domains": [
            "test.com",
            "domains.here",
            "uat",
            "prod"
          ]
        }
      ],
      "adguardUpstreams": []
    }
  ]
}

But seems like it doesn't change anything about trying to resolve e.g. "test.test.com" still return NXDOMAIN, but if I query the 10.10.10.10 manually - it will return proper info. Probably i've done something wrong?

Also, currently this is closest solution to kinda support this usecase, but it still require manually adding zones here, which is easier than doing it manually via zones tab, but still requires the manual intervention. So, would be nice if something like my initial idea was implemented.

[ShreyasZare]

But seems like it doesn't change anything about trying to resolve e.g. "test.test.com" still return NXDOMAIN, but if I query the 10.10.10.10 manually - it will return proper info. Probably i've done something wrong?

For this to work, make sure that cache entry is removed and also that your existing root zone is disabled.

You can check the cache tab on the panel and find the domain name you queried for. The cache data will tell you which server responded.

Also, currently this is closest solution to kinda support this usecase, but it still require manually adding zones here, which is easier than doing it manually via zones tab, but still requires the manual intervention. So, would be nice if something like my initial idea was implemented.

The request you have is really breaking the standards and is not really optimal since it will cause timeout errors before the expected forwarder is tried after attempting the prior ones. Plus, you will be leaking your internal domain names to the prior forwarders which is really not good to do so.

Thus using this app will be much better way to achieve this and it would be a one time config anyway.