MaginotDNS: How Inconsistent Bailiwick Checking Hijacks DNS Resolvers

TLDR: Researchers at Black Hat 2023 demonstrated that many conditional DNS resolvers fail to properly validate bailiwick rules when switching between forwarding and recursive modes. This flaw allows an attacker to poison the shared cache of a resolver by forcing it to accept malicious records for any domain, effectively hijacking traffic for entire TLDs. Pentesters should audit internal DNS configurations for these "conditional" setups, as they represent a significant, often overlooked, attack surface.

DNS cache poisoning is often treated as a solved problem, a relic of the pre-DNSSEC era that we only discuss in history books alongside the Kaminsky attack. We assume that modern resolvers are hardened, that source port randomization and strict bailiwick checking are standard, and that the "cat-and-mouse" game of the late 2000s is over. The research presented at Black Hat 2023 on MaginotDNS proves that assumption wrong. By exploiting the boundary between forwarding and recursive modes in conditional DNS resolvers, attackers can bypass these long-standing protections with ease.

The Flaw in the Boundary

Conditional DNS resolvers are common in enterprise and ISP environments. They are designed to be flexible, routing queries for internal domains to a local recursive resolver while forwarding everything else to a public DNS provider. The problem arises because these resolvers often use a shared cache for both modes.

The researchers discovered that when these resolvers are configured to handle both forwarding and recursion, their implementation of bailiwick checking becomes inconsistent. In a standard recursive resolver, the bailiwick rule is simple: the resolver only accepts records that are authoritative for the zone being queried. If you query example.com, the resolver will only accept records for example.com or its subdomains.

However, in the forwarding mode of these conditional resolvers, the implementation often defaults to a "root" zone configuration. Because the resolver assumes it is just passing traffic along, it fails to enforce the same strict validation it applies to its recursive queries. An attacker who can influence the upstream server—or simply spoof the response—can inject records that the resolver blindly caches. Once those records are in the shared cache, they are served to every client using that resolver, regardless of whether the client intended to use the forwarding or recursive path.

Exploiting the Shared Cache

The attack flow is elegant in its simplicity. An attacker identifies a target resolver that supports both forwarding and recursion. They then trigger a query that forces the resolver into its forwarding mode. By providing a malicious response that includes records for a target domain, the attacker poisons the shared cache.

The researchers demonstrated this against BIND9, Microsoft DNS, Knot DNS, and Technitium. In the case of BIND9, they utilized the SADDNS technique to guess source ports and brute-force transaction IDs (TXIDs). While SADDNS is a known technique, applying it to the forwarding boundary of a conditional resolver turns a difficult off-path attack into a reliable exploit.

For a pentester, this means that if you encounter a DNS server that acts as a forwarder for some zones and a recursive resolver for others, you have a high-value target. You are not just looking for a way to spoof a single record; you are looking for a way to poison the entire cache for the organization.

Practical Implications for Pentesters

During an engagement, you should map the DNS infrastructure to identify these conditional setups. If you find a resolver that forwards specific internal zones, test its bailiwick enforcement. You can use dig to query the resolver for a domain it is configured to forward and see if it accepts "out-of-bailiwick" records in the additional section of the response.

# Example of checking for bailiwick enforcement
dig @<target_resolver> <forwarded_domain>

If the resolver accepts records that do not belong to the forwarded zone, you have confirmed the vulnerability. The impact is total: you can redirect internal traffic to your own infrastructure, bypass authentication mechanisms that rely on DNS-based validation, or facilitate large-scale phishing campaigns.

Hardening the Infrastructure

Defending against this requires moving away from the "flexible" configurations that prioritize convenience over security. If you must use conditional forwarding, ensure that your DNS software is patched to the latest versions, as the vendors mentioned in the research have already released fixes for these specific implementation flaws.

More importantly, enforce strict DNSSEC validation wherever possible. While DNSSEC does not fix the underlying logic error in the resolver, it prevents the resolver from accepting the forged records that the MaginotDNS attack relies on. If the resolver cannot validate the signature of the injected record, it will discard it, effectively neutralizing the cache poisoning attempt.

The industry has spent decades building defenses like bailiwick checking, but we often forget that these defenses are only as good as their implementation. When software tries to be "too smart" by balancing multiple modes of operation, it often creates the very gaps that attackers are looking for. Stop assuming your DNS infrastructure is secure by default and start auditing the boundaries where your traffic is being routed. The next time you see a complex DNS configuration, don't just look at the routing rules—look at how the resolver decides what to trust.