Forwarders Fuel DNS Attacks: The Hidden Risk

Despite 250k devices removed by Koch's disclosure, transparent DNS forwarders remain a stagnant threat vector enabling massive amplification.

The math is brutal. While the broader ecosystem of open DNS devices collapsed from 25M to 1.4M between 2014 and 2026, Maynard Koch's weekly Internet-wide scans show this specific category refusing to shrink. These transparent DNS forwarders punch holes through shielded recursive resolvers by preserving spoofed source IPs, effectively scaling attack volume beyond traditional limits. They are the persistent backdoor in a system we thought was sealed.

This analysis dissects the operational mechanics allowing these forwarders to inject queries into anycast infrastructures without rewriting packet headers, evading standard rate limiting. We expose the firewall evasion architecture that turns private infrastructure into unwilling attack participants. Finally, we map the global vulnerability distribution, showing how concentrated deployment in specific economies sustains this exploitable surface despite a decade of remediation efforts.

The Operational Mechanics of Transparent DNS Forwarding and Source IP Preservation

Transparent DNS Forwarders as Incompletely Functional Components

A transparent DNS forwarder is an incompletely functional component that transfers requests without rebuilding packets, preserving the original source. Standard resolvers rewrite headers to mask client identity; these devices do not. By failing to reconstruct the packet, the forwarder forces the upstream recursive resolver to see a query originating directly from the spoofed victim address rather than the forwarding device. This behavior feeds spoofed traffic into open infrastructure, bypassing firewall rules designed to shield powerful anycasted resolvers from direct exposure (researchgate.net/publication/379087469_Swamp_of_Reflectors_Investigating_the_Ecosystem_of_Open_DNS_Resolvers).

Source IP spoofing here is not a client-side error. It is a protocol failure within the forwarding layer.

Transparent forwarders inject spoofed queries into shielded resolvers by preserving the original victim source IP during packet transfer. This mechanism grants attackers access to approximately 25,000 to 30,000 protected entities that would otherwise reject direct traffic. Unlike recursive forwarders, these devices do not handle amplified responses. They sustain attack volumes reaching 320 Mb at the victim without hitting local bandwidth caps. The architecture turns powerful anycasted infrastructure into unwilling participants in distributed reflection events. Attackers use this path to circumvent rate limiting policies applied to direct resolver access.

Google and Cloudflare resolvers appear on 76% of identified forwarders, concentrating risk within substantial anycast networks. This configuration allows malicious actors to exploit public DNS resolvers that typically enforce strict access controls. Because the packet is never rebuilt, the upstream resolver sees the query as originating directly from the spoofed address. Standard filtering focuses on the edge, missing this internal forwarding logic entirely. Mitigation requires disabling transparent redirection on customer-premises equipment and core routers alike. Default vendor settings prioritize connectivity over packet integrity, and that choice keeps this threat alive.

Circumventing Rate Limiting via DNS Anycast Infrastructure

Transparent forwarders bypass local throttling to use global anycast capacity for scalable amplification. Standard rate limiting fails because the forwarding device does not absorb the response traffic, shifting the bandwidth burden entirely to the upstream resolver. Attackers exploit this asymmetry to generate volumetric floods that exceed the 50 Mb egress limits typical of direct recursive attacks. The DNS anycast infrastructure distributes this load across hundreds of points of presence, making localized filtering ineffective against the aggregated stream. A controlled testbed using a MikroTik RB750Gr3 router demonstrated how this architecture allows malicious actors to reach 320 Mb of attack traffic at the victim while the forwarder itself remains under standard detection thresholds.

The flaw lies in the separation of query initiation and response reception. Operators relying on source IP reputation lists face a dead end: visible traffic originates from legitimate, high-capacity anycast nodes, not the compromised forwarder. Validating source IP consistency at the network edge before packets reach the recursive layer is the only fix.

Stateless Packet Forwarding and Source IP Preservation

Stateless packet forwarding preserves the spoofed source IP address because the device transfers DNS requests without rebuilding packets. This mechanical failure allows traffic to traverse network borders that typically block direct access to protected infrastructure. By failing to reconstruct the header, the forwarder ensures the upstream recursive resolver sees a query originating directly from the victim rather than the forwarding node. Research confirms this behavior effectively feeds spoofed traffic. The architecture creates a critical asymmetry: the forwarder handles minimal state while the upstream resolver processes the full amplification load.

Static rate limiting uses fixed thresholds; adaptive rate limiting is required to dynamically adjust to these evolving traffic patterns. Standard filtering fails because the forwarding device assumes any query is legitimate and does not absorb the response traffic. This design flaw grants attackers access to a vast subset of otherwise protected entities through firewall rules that validate destination but ignore source authenticity. The forwarder remains unaffected by the volumetric flood it helps generate. Stateless processing acts as a force multiplier for reflection attacks.

Attacker efficiency scales by targeting the majority of devices pointing to a single Google IP. Direct attacks on customer premises equipment yield limited return, but hijacking these forwarders unlocks the full egress capacity of tier-1 anycast networks. Blocking these legitimate resolver IPs breaks connectivity for valid users; allowing them permits amplification attacks to apply automated escalation techniques. The cost of mitigation shifts from the edge to the core, forcing substantial providers to absorb traffic spikes generated by misconfigured peripheral hardware.

Network engineers must enforce strict egress filtering that validates DNS query origins before they reach public anycast pools. Failure to isolate these forwarders leaves the global routing table vulnerable to scalable reflection events driven by centralized infrastructure.

Transparent vs Recursive Forwarders: Amplification and State Handling

Transparent forwarders bypass firewall validation by preserving the original source IP, exposing shielded resolvers to direct spoofed queries. Recursive forwarders rebuild packets to mask the client address; transparent variants transfer requests without modifying headers. This stateless behavior allows attackers to trigger responses from protected infrastructure that normally rejects direct traffic. The forwarder assumes legitimacy for every query, minimizing internal state tables and avoiding the resource exhaustion that limits recursive devices. Consequently, the attacking node does not need to handle the amplified reply, shifting the entire bandwidth burden to the upstream resolver.

The lack of response handling creates a severe asymmetry in attack scalability. While recursive setups hit local bandwidth caps near 50 Mb during flooding, transparent configurations sustain much higher volumes at the victim site. Lab tests indicate these devices reach up to 320 Mbit/s. This efficiency unlocks access to approximately 25,000 to 30,000 shielded resolvers previously deemed safe from reflection tactics. Standard ingress filtering fails when the forwarding device itself acts as the blind conduit.

SNMP and Banner Grabbing for Transparent Forwarder Fingerprinting

Active scanning with ZGrab, SNMP scanner, and Selenium extracted signatures from 13,072 devices, representing 2.5% of the estimated global pool. Researchers deployed these tools to perform banner grabbing and protocol queries against the accessible infrastructure. The process isolates specific hardware models by analyzing response headers and management interface data. Device diversity extends beyond routing gear to include network video recorders from vendors like HikVision.

Geographic concentration complicates mitigation efforts, with Brazil and India hosting the majority of identified units. The low identification rate implies that the vast majority of forwarders suppress management traffic or disable SNMP entirely. Operators relying solely on active probes miss the silent majority of vulnerable nodes. Passive flow analysis becomes necessary to detect forwarders that do not respond to direct interrogation.

Brazil hosts 31% and India holds 24% of all globally accessible transparent DNS forwarders. This extreme geographic concentration creates a localized attack surface where operators in these two economies control the majority of potential reflectors. Detection requires scanning for devices that forward UDP port 53 traffic without rewriting the source IP, a behavior distinct from standard recursive resolvers. Fixing open DNS forwarder exposure demands that network administrators disable transparent DNS proxy features on edge routers or implement strict ingress filtering at the autonomous system boundary. The bias toward these regions means remediation efforts yield disproportionate global security benefits when focused locally.

The presence of cameras indicates that fingerprinting scans must target non-standard ports used by surveillance equipment. Ignoring these non-router assets leaves a significant portion of the reflection infrastructure active despite router remediation efforts.

Strategic Mitigation Steps for Securing Recursive Resolvers and Preventing Amplification

Why Transparent Forwarders Bypass Standard Rate Limiting

Static rate limiting fails against transparent forwarders because these devices minimize state tables and assume every query is legitimate. Unlike recursive resolvers that rebuild packets, transparent variants forward requests without modifying headers, allowing spoofed source IPs to reach shielded infrastructure directly. This mechanism enables attackers to access shielded recursive resolvers that normally reject direct traffic, effectively bypassing firewall rules designed to protect internal networks. The forwarder does not process the amplified response, shifting the entire bandwidth burden to the victim while the attacker maintains low overhead. Operational mitigation requires moving beyond fixed thresholds to adaptive policies that inspect packet provenance rather than volume alone.

1. Disable transparent DNS proxy features on edge routers to force packet reconstruction.
2. Implement strict ingress filtering at the autonomous system boundary to drop spoofed sources.
3. Deploy adaptive rate limiting that dynamically adjusts based on query legitimacy signals.

Lab tests confirm that a single compromised router can generate 320 Mbit/s. This disparity exists because the forwarder avoids the resource exhaustion that typically throttles direct attacks. Maintaining smooth user connectivity conflicts with enforcing strict packet validation that may introduce latency, but the alternative is unacceptable.

Configuring Firewall Rules to Block Direct Resolver Access

Border firewalls often trust traffic originating from local gateway IPs, which allows direct access to internal resolvers to persist. Operators must audit router configurations to ensure network ingress filtering rejects packets with spoofed source addresses before they reach protected assets. This step closes the gap where transparent forwarders rewrite headers to bypass standard perimeter defenses.

1. Enable Reverse Path Forwarding checks on all edge interfaces to validate packet origin legitimacy against the routing table.
2. Apply explicit access control lists that block UDP port 53 traffic from untrusted internal subnets destined for recursive resolvers.
3. Disable transparent DNS proxy features on customer-premises equipment to prevent unintended packet forwarding without source reconstruction.

Securing infrastructure independently of the main network firewall prevents attackers from using compromised gateways as entry points. Measurements indicate that transparent setups can generate attack volumes reaching 320 Mbit/s. This throughput exceeds the capacity of many standard rate-limiting policies designed for direct recursion. Strict filtering may drop legitimate traffic if asymmetric routing paths exist within the autonomous system, yet failure to secure these internal boundaries allows threat actors to access shielded recursive resolvers that were presumed safe behind corporate perimeters. Internal devices become the primary vector for external amplification events, creating a false sense of security.

Implementing Reverse Path Forwarding and Ingress Filtering

Networks with transparent forwarders often omit network ingress filtering, allowing spoofed traffic to bypass perimeter defenses. Operators must deploy these checks to stop reflective amplification at the edge.

1. Enable Reverse Path Forwarding on all edge interfaces to drop packets with invalid source IPs.
2. Configure access control lists that explicitly block UDP port 53 from untrusted internal subnets.
3. Audit router configurations to ensure transparent DNS proxy features remain disabled on customer-premises equipment.

Shielded resolvers remain exposed to unauthorized queries when organizations fail to implement these controls. Attackers exploit this gap to access shielded recursive resolvers that normally reject direct traffic. Transparent forwarders transfer DNS requests without rebuilding packets, meaning the source IP address included in the query remains the IP address of the original resolver, effectively feeding spoofed traffic. InterLIR recommends validating these rules weekly, as static configurations frequently drift during routine maintenance windows.