Problem
No validation prevents a forwarder from pointing back at one of the server's own DNS endpoints. DnsServer.Forwarders accepts configured forwarders without comparing them against the server's listener configuration, and the Advanced Forwarding app has the same gap.
This is a real configuration-safety and availability issue, but not an unbounded recursion vulnerability. It requires administrative control over forwarding configuration, and only queries using the offending forwarder are affected. Security severity is therefore low, but operational impact can be significant because resolution fails with little indication of the actual cause.
_resolverMaxStackCount does not catch this because it limits recursive hostname resolution, not forwarding hops. RECURSIVE_RESOLUTION_TIMEOUT also does not bound the direct-forwarding path.
Instead, _resolverTasks prevents recursive amplification. When the forwarded copy of the same question returns to the server, it finds the existing resolver task and waits for it. After the applicable client timeout, the request returns SERVFAIL with "Waiting for resolver. Please try again." The original forwarding operation then unwinds according to its own timeout and retry behaviour.
The failure is therefore bounded, but difficult to diagnose and causes unnecessary forwarding and retry work.
This issue covers direct self-reference only. A cycle such as A → B → A requires separate runtime or cross-server loop detection.
Fix
Reject a forwarder if its effective destination maps to an active DNS endpoint provided by the same DNS Server configuration.
The check should use configured listener addresses, enabled DNS transports, and configured ports. It should not discover listening ports from the operating system or assume defaults. DnsServer.LocalEndPoints is part of this state, but is not a complete representation of all DNS endpoints.
The check should handle wildcard listeners, loopback and local addresses, IPv4/IPv6 normalization, hostname-based targets, and transport-specific ports. Hostname targets should also be rechecked when their resolved address changes.
For Advanced Forwarding, prefer exposing a semantic self-endpoint check through IDnsServer rather than exposing raw listener configuration and duplicating the logic.
Value
Turns a hard-to-diagnose SERVFAIL into an immediate configuration error, avoids unnecessary forwarding and retry work, and provides one reusable validation path for core and Advanced Forwarding.
Problem
No validation prevents a forwarder from pointing back at one of the server's own DNS endpoints.
DnsServer.Forwardersaccepts configured forwarders without comparing them against the server's listener configuration, and the Advanced Forwarding app has the same gap.This is a real configuration-safety and availability issue, but not an unbounded recursion vulnerability. It requires administrative control over forwarding configuration, and only queries using the offending forwarder are affected. Security severity is therefore low, but operational impact can be significant because resolution fails with little indication of the actual cause.
_resolverMaxStackCountdoes not catch this because it limits recursive hostname resolution, not forwarding hops.RECURSIVE_RESOLUTION_TIMEOUTalso does not bound the direct-forwarding path.Instead,
_resolverTasksprevents recursive amplification. When the forwarded copy of the same question returns to the server, it finds the existing resolver task and waits for it. After the applicable client timeout, the request returnsSERVFAILwith "Waiting for resolver. Please try again." The original forwarding operation then unwinds according to its own timeout and retry behaviour.The failure is therefore bounded, but difficult to diagnose and causes unnecessary forwarding and retry work.
This issue covers direct self-reference only. A cycle such as A → B → A requires separate runtime or cross-server loop detection.
Fix
Reject a forwarder if its effective destination maps to an active DNS endpoint provided by the same DNS Server configuration.
The check should use configured listener addresses, enabled DNS transports, and configured ports. It should not discover listening ports from the operating system or assume defaults.
DnsServer.LocalEndPointsis part of this state, but is not a complete representation of all DNS endpoints.The check should handle wildcard listeners, loopback and local addresses, IPv4/IPv6 normalization, hostname-based targets, and transport-specific ports. Hostname targets should also be rechecked when their resolved address changes.
For Advanced Forwarding, prefer exposing a semantic self-endpoint check through
IDnsServerrather than exposing raw listener configuration and duplicating the logic.Value
Turns a hard-to-diagnose
SERVFAILinto an immediate configuration error, avoids unnecessary forwarding and retry work, and provides one reusable validation path for core and Advanced Forwarding.