Conditional Forwarder Zone FWD records seem to ignore global Forwarder Concurrency setting

[PlusaN]

Hi,

I would like to report what appears to be an inconsistency in forwarding behavior between global forwarders and FWD records used in Conditional Forwarder Zones.

Observed behavior

On my Technitium DNS setup:

• Enable Concurrent Forwarding is enabled
• Forwarder Concurrency is set to 2
• I have a Conditional Forwarder Zone for example.com
• Inside that zone, I created 4 FWD records pointing to 4 different DNS servers

When I query any record under example.com and inspect the traffic with tcpdump, I can see that the DNS server sends requests to all 4 configured FWD targets at the same time, instead of limiting concurrent upstream queries to 2.

This makes it look like the global Forwarder Concurrency setting is applied to global forwarders, but not to FWD records inside Conditional Forwarder Zones.

Why this matters

Using only Priority to control this behavior is not always convenient enough.

A practical example is a clustered multi-datacenter deployment:

• several Technitium DNS servers are deployed in different locations
• a clustered Conditional Forwarder Zone is shared between them
• the zone contains multiple FWD records pointing to all available upstream DNS servers (for example, AD DC/DNS servers across sites)

In such a setup, it would be very useful if the server could:

1. consider all configured FWD targets
2. apply a concurrency limit (for example, 2)
3. select the best candidates using the existing latency-based logic
4. use the fastest valid response

This would allow both:

• cross-site resiliency/failover
• avoiding unnecessary fan-out to every configured upstream server for each query

Expected behavior

It would be great if one of the following could be implemented:

Option 1

Apply the existing global Forwarder Concurrency setting to FWD records in Conditional Forwarder Zones as well.

Option 2

Introduce a zone-specific setting for Conditional Forwarder Zones, for example:

• Conditional Forwarder Concurrency
• or per-zone override of forwarding concurrency

That would make it possible to control concurrent querying behavior more precisely for clustered/site-aware deployments.

Related use case

In my case, I would like a clustered Conditional Forwarder Zone to forward queries to multiple upstream DNS servers across datacenters, while still respecting concurrency limits and the existing "fastest forwarder" logic, instead of querying every FWD target simultaneously.

This would fit very well with the documented forwarding behavior:

The DNS server will automatically select forwarders (based on their average latency) to query and use the fastest response it receives from any of them.

Suggestion

Please consider making FWD records in Conditional Forwarder Zones respect Forwarder Concurrency, or adding a separate concurrency control specifically for conditional forwarders.

Thanks!

[ShreyasZare]

Thanks for the post. This is done by design to prevent issues with the Priority feature. Currently, the forwarder zone will attempt to forward based on the priority values of the FWD records. The lower value records are tried first. Lets say, there are 4 FWD records with priority 0. They will be tried first together and if none of them answers or the timeout occurs, the next FWD records are selected by incrementing priority.

If the concurrency is limited to say 2, the priority 0 task would take 2x time to complete if all 4 upstreams do not respond. The more the number of FWD records, the more time it will take to move to the next priority. This will potentially cause several ServerFailure errors to clients by that time. With the current model, a single priority level always takes same amount of time no matter how many FWD records are there.

Due to this issue that affects the priority feature, there is no support to limit concurrency for forwarder zones.

[PlusaN]

Thanks for the clarification. That makes sense regarding the current priority model and why limiting concurrency for forwarder zones would conflict with it.

Would it perhaps make sense to support something similar to the Advanced Forwarding app, but not as a global server-wide feature and instead as APP records inside a Conditional Forwarder Zone?

For example, instead of using only regular FWD records, it could be useful to have an APP record type for forwarder zones where it would be possible to define:

• which forwarders should be used for specific client subnets
• priority values per subnet/group
• possibly different upstream sets for different locations/networks

This could allow more flexible site-aware forwarding behavior inside a clustered Conditional Forwarder Zone, without changing the current behavior of standard FWD records or the existing priority model.

A practical use case would be a multi-datacenter deployment where the same clustered forwarder zone exists on all nodes, but clients from different subnets should prefer different local upstream DNS servers, with remote locations used only as fallback.

So the idea would be something like:

• keep standard FWD records unchanged
• optionally allow APP-based forwarding policy inside the forwarder zone
• subnet-aware upstream selection with priorities, similar in concept to Advanced Forwarding

Do you think something like this would be feasible or make sense architecturally?

[ShreyasZare]

The Advanced Forwarding app can be used to forward only specific domain names and you can map that to specific subnets. So what you are expecting is already available using this app. The app however too does not use the concurrent forwarding feature which is something that can be added.

Making another feature that use APP record along side FWD records will just complicate the feature and make it difficult to get it configured correctly.

[PlusaN]

Thanks, that makes sense.

I agree that having concurrent forwarding support in Advanced Forwarding would be very useful.

At the same time, there is still one part of the current behavior that is not fully clear to me.

My original idea was actually to use Advanced Forwarding for this scenario, since its current subnet-based forwarding model is exactly what I need in general. The problem I ran into is that it does not seem to work for a Conditional Forwarder Zone in the way I expected.

My current setup is roughly the following:

• Advanced Forwarding is installed and configured
• different client subnets are mapped to different forwarders
• Proxy & Forwarders -> Forwarders is empty
• a Conditional Forwarder Zone exists for example.com

Example Advanced Forwarding configuration:

{
  "appPreference": 200,
  "enableForwarding": true,
  "forwarders": [
    {
      "name": "cloudflare",
      "proxy": null,
      "dnssecValidation": true,
      "forwarderAddresses": [
        "1.1.1.1"
      ]
    },
    {
      "name": "localdns",
      "proxy": null,
      "dnssecValidation": false,
      "forwarderAddresses": [
        "192.168.0.1"
      ]
    }
  ],
  "networkGroupMap": {
    "0.0.0.0/0": "everyone",
    "192.168.2.0/24": "localnetwork"
  },
  "groups": [
    {
      "name": "everyone",
      "enableForwarding": true,
      "forwardings": [
        {
          "forwarders": [
            "cloudflare"
          ],
          "domains": [
            "*"
          ]
        }
      ]
    },
    {
      "name": "localnetwork",
      "enableForwarding": true,
      "forwardings": [
        {
          "forwarders": [
            "localdns"
          ],
          "domains": [
            "*"
          ]
        }
      ]
    }
  ]
}

After testing different configurations in the Conditional Forwarder Zone, I observed the following:

1. If the zone contains no records except the default SOA, then queries for names under example.com return that the record does not exist.
   This is expected.

2. If I create FWD records in the zone pointing to 192.168.0.1, then queries for names in that zone are forwarded according to the FWD records and their priority.
   This is also expected.

3. If I create an FWD record with Use "This Server" enabled, then queries are forwarded using the server's normal forwarding behavior and end up going to the external authoritative/public DNS path for that domain.
   My question here is: should this path use the Advanced Forwarding rules, or is it expected that it does not?

4. The most interesting case: if I install any app that enables APP records in the Conditional Forwarder Zone (for example, Wild IP), and then create an APP record with name @ and no parameters, queries for subdomains such as test.example.com start following my Advanced Forwarding rules correctly, including subnet-based forwarder selection.

   However, a query for the zone apex itself, example.com, still returns that the record does not exist.

This last case is the most confusing one.

In practice, this behavior is actually close to what I would like to achieve, because it makes the Conditional Forwarder Zone work through the Advanced Forwarding logic for subdomains. But I do not understand whether this is:

• expected behavior
• an implementation side effect
• or a bug

So my questions are:

1. Is it expected that Advanced Forwarding does not apply to a Conditional Forwarder Zone unless something like an APP record exists in the zone?
2. Is the behavior with an APP record at @ causing subdomain queries to follow Advanced Forwarding rules an intended feature, or just an accidental side effect?
3. Should FWD with Use "This Server" be expected to use Advanced Forwarding rules, or not?

Also, regarding Advanced Forwarding itself: if multiple forwarders are listed in a group's forwarders array, am I correct in understanding that they are queried concurrently?

And if so, is there any way to define priority there as well, similar to FWD records, so that it would be possible to have something like primary forwarders and fallback/backup forwarders within Advanced Forwarding?

Thank you again for this project and also for taking the time to answer all of my questions. I really appreciate it.

[ShreyasZare]

If I create an FWD record with Use "This Server" enabled, then queries are forwarded using the server's normal forwarding behavior and end up going to the external authoritative/public DNS path for that domain.
My question here is: should this path use the Advanced Forwarding rules, or is it expected that it does not?

This is expected since local zones have higher priority so any response they generate will be used by the DNS server to respond to requests.

The most interesting case: if I install any app that enables APP records in the Conditional Forwarder Zone (for example, Wild IP), and then create an APP record with name @ and no parameters, queries for subdomains such as test.example.com start following my Advanced Forwarding rules correctly, including subnet-based forwarder selection.

However, a query for the zone apex itself, example.com, still returns that the record does not exist.

The APP record causes the zone to return null response so that the DNS server can do other processing to resolve the request. In such case, the other apps get a chance to respond.

The Conditional Forwarder zone is a proprietary zone and does not work like a primary zone. The purpose of this zone is to allow forwarding using FWD records and to allow overriding records for split horizon scenarios. Combining this zone with Advanced Forwarding app may thus give unexpected results like you are observing. This is kind of expected since its the way the forwarder zone is working to answer what it knows and if it does not have any answer, the control goes away from it to another app which can answer more precisely.

Also, regarding Advanced Forwarding itself: if multiple forwarders are listed in a group's forwarders array, am I correct in understanding that they are queried concurrently?

Yes, all forwarders are queried concurrently similar to FWD records with same priority value. The fastest and correct answer is used by the DNS server.

And if so, is there any way to define priority there as well, similar to FWD records, so that it would be possible to have something like primary forwarders and fallback/backup forwarders within Advanced Forwarding?

There is no option to do that in the app. Priority feature is available only with Conditional Forwarder zones. Options like priority were added to address certain scenarios. Without an actual scenario, adding such option would cause the config to become complex for normal users.

Thank you again for this project and also for taking the time to answer all of my questions. I really appreciate it.

You're welcome.

[PlusaN]

Thanks again for the detailed explanation.

I would like to ask about one possible feature idea related to integrating Conditional Forwarder Zones with Advanced Forwarding in a more intentional and supported way.

Would it be possible to provide some kind of official handoff/integration mechanism between a Conditional Forwarder Zone and the Advanced Forwarding app?

What I mean is not an APP record that "does nothing", but rather a supported way for a Conditional Forwarder Zone to delegate unresolved queries to Advanced Forwarding logic for that zone.

This is actually the kind of functionality I would ideally like to have.

The idea would be:

• use Advanced Forwarding for the global logic of routing queries to the appropriate forwarders depending on the client subnet
• still be able to use a Conditional Forwarder Zone for a specific domain
• and inside that zone, still be able to override or control some records more precisely with other apps when needed

At the moment, a very similar effect can already be achieved indirectly by using Advanced Forwarding together with any other app that allows creating an APP record inside the Conditional Forwarder Zone. In that case, the zone seems to return null, and then Advanced Forwarding gets a chance to process the request.

I could already use this behavior today to implement the design I have in mind, but I would prefer not to rely on something that was not intended as part of the general design, since there is always a chance that this behavior may change in the future.

What I am interested in is whether something similar could be intentionally supported as a proper feature.

My use case is the following:

• a clustered installation across multiple datacenters
• multiple DNS servers in each location
• this is the key point: if each datacenter had its own separate cluster, then this could be solved much more easily with FWD record priorities alone

There is an internal zone, example.com, served by AD domain controllers, with different DCs in each datacenter.

The desired flow would be:

1. Configure Advanced Forwarding so that:

   • clients from datacenter1 subnets use DCs from datacenter1 for example.com
   • clients from datacenter2 subnets use DCs from datacenter2 for example.com

2. Create a cluster-synchronized Conditional Forwarder Zone for example.com

3. Allow that zone to hand off unresolved queries to Advanced Forwarding logic for subnet-aware forwarder selection

With this model, the result would be:

• the zone is clustered and synchronized across all servers in all datacenters
• forwarder selection still happens dynamically based on client subnet
• unnecessary cross-datacenter DNS traffic is avoided
• and at the same time, it becomes possible to manage some specific records more flexibly using other apps such as Failover or Split Horizon

If FWD records in Conditional Forwarder Zones behaved the same way as global forwarders, including Forwarder Concurrency and forwarder selection based on latency, that would also solve my original problem.

But an intentional integration/handoff model with Advanced Forwarding would also work very well for my scenario.

Do you think something like this would be feasible architecturally, as a supported integration point between Conditional Forwarder Zones and Advanced Forwarding?

[ShreyasZare]

Do you think something like this would be feasible architecturally, as a supported integration point between Conditional Forwarder Zones and Advanced Forwarding?

Such an implementation is really not feasible. Both the zones and apps work independently so trying to integrate it this way would be an issue. There are multiple issues involved in this, primarily how the current implementation works and secondly how the app supports subnet specific forwarding while the zones do not support such thing.

If FWD records in Conditional Forwarder Zones behaved the same way as global forwarders, including Forwarder Concurrency and forwarder selection based on latency, that would also solve my original problem.

You can just let the forwarder zone hit all the upstreams, it really does not matter since the fastest response is used. The other option you have is to list only 2-3 upstreams instead of all of them which will still perform the same and have redundancy.

[PlusaN]

Thank you again for taking the time to explain all of this in detail.

After reviewing your answers and rethinking the design, I ended up with a different solution which, in some ways, actually works better for my use case. I am sharing it here in case it may also be useful for someone else.

My original goal was to combine:

• subnet-aware forwarding using Advanced Forwarding
• a clustered Conditional Forwarder Zone
• and the ability to use APP-based logic for some specific records

After this discussion, I realized that trying to combine all of that on the same domain was making the design unnecessarily complex.

The approach I settled on is the following:

1. Keep Advanced Forwarding exactly for what it already does well:

   • route queries for example.com to the appropriate AD DC/DNS servers depending on the client subnet / datacenter

2. Remove the Conditional Forwarder Zone for example.com

3. Create a separate internal zone, for example something like example.local (or another dedicated internal zone name)

4. In that internal zone, create the APP-based records that need more dynamic behavior

5. In the main example.com zone hosted on the AD DCs, create CNAME records pointing to the corresponding records in that internal Technitium-managed zone

With this model:

• example.com continues to be resolved through Advanced Forwarding using the correct DCs for each location
• the dynamic/special logic is handled in a separate Technitium-managed zone
• I can still use apps such as Split Horizon / Failover / etc. for specific records
• and I avoid unnecessary cross-datacenter DNS traffic

For my multi-datacenter clustered setup, this turned out to be a much cleaner design than trying to make Conditional Forwarder Zones and Advanced Forwarding work together on the same domain.

So in the end, this discussion was very helpful, because it pushed me toward a solution that is actually simpler and more aligned with how these features are designed to work.

One thing that would still be very useful in the future, however, would be optional priority support in Advanced Forwarding.

I think this could be implemented as an optional parameter, so that the configuration remains simple for users who do not need it.

In my case, such a feature would allow more flexible failover behavior. For example:

• local DC/DNS servers could be assigned the lowest priority value
• remote datacenter DC/DNS servers could be assigned a higher priority value
• in normal operation, queries would only go to the local servers
• and only if the local servers were unavailable, queries would fall back to the remote ones

That would make it possible to keep the current subnet-aware forwarding model of Advanced Forwarding, while also making failover behavior more selective and location-aware.

Thanks again for both the project and your detailed replies.

[ShreyasZare]

You're welcome. Good to know you have a solution which is working better.

[PlusaN]

After all the discussion and testing, I think the subject of this request has changed to:

Advanced Forwarding app ignores the global Forwarder Concurrency setting

Do you see support for the concurrent forwarding feature as a possible future enhancement for the Advanced Forwarding app?

[ShreyasZare]

Do you see support for the concurrent forwarding feature as a possible future enhancement for the Advanced Forwarding app?

Thanks for asking. Will review the implementation once and see how this can be improved.

[ShreyasZare]

Do you see support for the concurrent forwarding feature as a possible future enhancement for the Advanced Forwarding app?

I just did analysis on how this is implemented with the app and it is not really feasible to implement in there too. The app too is relying on the same internal feature that the Conditional Forwarder zones use.