| Internet-Draft | Enhanced Bailiwick Checking | July 2025 |
| Qiu & Li | Expires 20 January 2026 | [Page] |
The Domain Name System (DNS) relies on caching to function efficiently. However, DNS cache poisoning remains a significant threat. The "bailiwick" rule is a fundamental security mechanism intended to prevent resolvers from caching out-of-bailiwick data sent by malicious or misconfigured authoritative servers. Current DNS standards provide high-level guidance on bailiwick checking but lack specific algorithmic definitions, leading to inconsistent implementations across different DNS software. These inconsistencies can be exploited, particularly in DNS servers that operate in multiple modes, such as Conditional DNS Servers (CDNS), which may act as both recursive resolvers and forwarders and often share a common cache.¶
This document specifies enhanced and more precise rules for bailiwick checking in DNS resolvers, including those operating as forwarders or CDNS. The goal is to provide clearer guidelines for implementers, reduce the attack surface for cache poisoning, and improve the overall security and robustness of the DNS infrastructure. The recommendations herein are informed by recent research highlighting vulnerabilities in existing bailiwick implementations.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 2 January 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Bailiwick checking is a critical defense mechanism in the DNS designed to ensure that a DNS server only accepts and caches data for which the responding server is authoritative. As defined in [RFC1034] and [RFC1035], authoritative nameservers should not return data for zones they do not manage. Resolvers are expected to enforce this by discarding "unsolicited" or out-of-bailiwick data.¶
However, the precise algorithms for bailiwick checking are not rigorously defined in existing standards, leading to diverse interpretations and implementations by DNS software vendors. Recent research, such as "The Maginot Line: Attacking the Boundary of DNS Caching Protection" [MAGINOTDNS], has exposed vulnerabilities stemming from these inconsistencies. These vulnerabilities can allow attackers to inject malicious records into a resolver's cache, potentially hijacking entire DNS zones, including Top-Level Domains (TLDs).¶
Conditional DNS Servers (CDNS), which combine recursive resolver and forwarder functionalities and often share a global cache, present a particular challenge. Weaknesses in the bailiwick checks of one mode (e.g., forwarding) can be exploited to poison the cache used by another, more secure mode (e.g., recursive resolution).¶
This document aims to address these issues by providing more explicit and robust rules for bailiwick checking. The goal is to foster more consistent and secure implementations across DNS resolver software, thereby strengthening the overall resilience of the DNS ecosystem against cache poisoning attacks.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses standard DNS terminology as defined in [RFC1034], [RFC1035], and [RFC8499]. The following terms are central to this document:¶
The scope of authority a nameserver has. Data is considered "in-bailiwick" if it pertains to the zone(s) for which the responding nameserver is authoritative in the context of the original query.¶
Data that is not within the bailiwick of the responding nameserver.¶
The domain name in the question section of the current query being processed by the resolver.¶
The type of the resource record (RR) in the question section of the current query.¶
The closest ancestor zone for which the resolver has (or believes it has) authoritative nameserver information relevant to Q.NAME. This zone defines the current bailiwick against which incoming response records are checked. The determination of Q.ZONE is critical and is further detailed in Section 3.2.¶
A single record in a DNS response. RR.NAME is the owner name of the resource record. RR.TYPE is the type of the resource record. RR.DATA is the data content of the resource record.¶
A DNS server configured to act as both a recursive resolver and a forwarder simultaneously, often directing queries to different upstream servers or resolving them differently based on the queried domain name. CDNS implementations typically use distinct sets of zones:¶
$Z_R$ (Recursive DNS Zones): The set of domain names for which the CDNS is configured to perform recursive resolution.¶
$Z_F$ (Forwarding DNS Zones): The set of domain names for which the CDNS is configured to forward queries to specific upstream forwarders.¶
The process by which a nameserver for a parent zone indicates the authoritative nameservers for a child zone, typically via NS records.¶
A DNS response from a nameserver that does not have the authoritative answer for a query but provides NS records (and potentially glue records) pointing to nameservers that are authoritative for a zone closer to the Q.NAME.¶
The process of examining each RR in a DNS response to determine if it is in-bailiwick and should be processed and potentially cached.¶
The concept of bailiwick is fundamental to DNS security. [RFC1034] states that nameservers should not add RRs to the additional section unless they are "closely related to an RR in the answer or authority sections". More generally, data returned by a nameserver should be within the scope of the zones for which it holds authority, relative to the query that was made. Resolvers are expected to discard data that violates this principle [RFC2181].¶
The primary goal of bailiwick checking is to prevent a malicious
nameserver authoritative for example.com from providing (and a
resolver from caching) records for other-example.net, or worse,
for TLDs or the root zone.¶
Despite the long-standing principle of bailiwick, its implementation varies. The [MAGINOTDNS] study highlights several critical areas of inconsistency and vulnerability:¶
Q.ZONE Initialization: In forwarding mode, some DNS software initializes Q.ZONE to overly broad zones (e.g., the root zone ".") or an ancestor of Q.NAME that is too high in the DNS hierarchy. This effectively weakens or nullifies bailiwick checks for records in the authority and additional sections, as almost any record would appear to be "in-bailiwick" relative to the root. This is referred to as V1 in [MAGINOTDNS].¶
CNAME Chasing Logic: Flaws in how bailiwick context is maintained or re-evaluated during CNAME chasing can lead to vulnerabilities where a resolver is tricked into accepting out-of- bailiwick data for the CNAME target. This is referred to as V2 in [MAGINOTDNS].¶
Shared Cache in CDNS: When recursive and forwarding modes in a CDNS share a global cache, data cached via the potentially weaker bailiwick checks of the forwarding mode can pollute the cache for the recursive mode.¶
These inconsistencies underscore the need for more precise normative guidance.¶
CDNS are increasingly common in enterprise networks and ISP infrastructure. They offer flexible query routing, allowing organizations to resolve internal domains locally while forwarding external domains to public resolvers, or to implement split-horizon DNS, content delivery optimizations, or security policies.¶
The dual nature of CDNS, coupled with shared caching, makes them a prime target if bailiwick checks are inconsistent between modes. An attacker might exploit a vulnerability in the forwarding path's bailiwick logic to inject malicious data that subsequently affects recursive resolution for other clients or other domains.¶
The following general principles MUST be applied by DNS resolvers when processing responses and considering records for caching:¶
A resolver MUST NOT cache any RR from a response if that RR is determined to be out-of-bailiwick according to the rules specified in this document.¶
The bailiwick checks applied to data received in forwarding mode MUST be at least as stringent as those applied in recursive resolution mode if the forwarded data can be stored in a cache that is also accessible by the recursive resolution process.¶
The Q.ZONE for a query is established at the time the query is sent and is used to validate the response. It represents the zone for which the queried upstream server is considered authoritative in the context of the current Q.NAME.¶
The correct determination of Q.ZONE is paramount for effective bailiwick checking.¶
When a resolver is performing recursive resolution and is about to send a query for Q.NAME to a set of selected authoritative nameservers:¶
Q.ZONE MUST be set to the name of the zone for which the selected upstream nameservers are authoritative. This is typically the closest ancestor of Q.NAME (or Q.NAME itself) for which the resolver has NS records in its cache, or the root zone (".") if no closer NS records are available.¶
When a resolver is configured to forward queries for domains within a specific forwarding zone ($Z_F$) to a designated set of upstream forwarders:¶
If the Q.NAME falls within a configured forwarding zone $Z_F$
(e.g., Q.NAME is host.internal.example.com and $Z_F$ is
internal.example.com), then Q.ZONE for the query sent to the
upstream forwarder SHOULD be set to that $Z_F$
(internal.example.com).¶
If the resolver is acting as a general-purpose forwarder (e.g., forwarding all queries for which it is not authoritative itself) and is configured to forward to a specific recursive resolver (e.g., a public DNS service), Q.ZONE SHOULD be considered the root zone ("."). However, if this forwarder caches responses and that cache is shared with a recursive resolution component (as in a CDNS), this broad Q.ZONE definition is insufficient. See Section 4 for CDNS-specific rules.¶
A resolver in forwarding mode, especially if part of a CDNS that shares its cache with a recursive component, MUST NOT initialize Q.ZONE to the root zone (".") or an overly broad ancestor if a more specific zone context (like a configured $Z_F$) is available for Q.NAME. Relying on an upstream recursive resolver to perform all bailiwick checks is NOT SUFFICIENT if the forwarding resolver itself caches the results in a shared cache.¶
If a forwarder forwards to an authoritative server directly (not a recursive resolver), Q.ZONE MUST be the zone for which that authoritative server is believed to be authoritative for Q.NAME.¶
Upon receiving a response (R) to a query (Q), each RR in the answer, authority, and additional sections of R MUST be checked against Q.ZONE.¶
For an RR in the answer section to be considered in-bailiwick:¶
a. RR.NAME MUST be equal to Q.NAME (or an alias of Q.NAME if CNAMEs/DNAMEs are involved, see Section 3.4).¶
b. RR.TYPE MUST be equal to Q.TYPE (unless Q.TYPE is ANY or CNAME/DNAME processing is occurring).¶
c. If RR.TYPE is CNAME or DNAME, specific CNAME/DNAME processing rules apply (see Section 3.4 and [RFC6672]).¶
Records in the answer section that do not meet these criteria MUST be discarded and NOT cached, unless they are part of a valid CNAME/DNAME chain leading to the Q.NAME.¶
The additional section typically contains address records (A/AAAA) for nameservers listed in the authority or answer sections (glue records), or other records deemed helpful by the authoritative server.¶
For an RR in the additional section to be considered in- bailiwick:¶
a. It MUST be "closely related" to an RR that is itself in- bailiwick in the answer or authority sections. "Closely related" typically means RR.NAME is the RDATA of an in- bailiwick NS record (glue for a nameserver name) or an in- bailiwick MX or SRV record.¶
b. Specifically for glue records (A/AAAA for an NSDNAME appearing in an in-bailiwick NS record's RDATA): RR.NAME (the nameserver's name) MUST be within the zone being delegated by that NS record (i.e., a sub-domain of or equal to the owner name of the NS record) or within Q.ZONE. Glue for out-of-zone nameservers is permissible but the address records themselves are only authoritative if they are also within Q.ZONE. Non-authoritative glue may be cached but should be treated with lower trust [RFC2181].¶
Records in the additional section that are not closely related to in-bailiwick records in other sections, or whose RR.NAME is not justified by Q.ZONE or a valid delegation, MUST be discarded and NOT cached.¶
When a resolver receives a CNAME (or DNAME) record in response to a query for Q.NAME:¶
The CNAME/DNAME record itself MUST be validated as per Section 3.3.1. (i.e., RR.NAME must match Q.NAME).¶
The resolver then initiates a new query for the canonical name (the target of the CNAME/DNAME). The Q.ZONE for this new query MUST be determined based on the new Q.NAME (the canonical name) as per rules in Section 3.2.1. It MUST NOT simply inherit the Q.ZONE of the original query if the canonical name falls into a different bailiwick context.¶
Resolvers MUST validate the entire CNAME chain. Each CNAME in the chain must point to a name for which the subsequent CNAME or the final answer is in-bailiwick with respect to the Q.ZONE established for that specific lookup in the chain. This prevents exploitation of CNAMEs to inject unrelated data (addressing V2 from [MAGINOTDNS]).¶
CDNS often use a shared global cache for records obtained via both recursive resolution and forwarding. This presents a significant risk if bailiwick checks for forwarded data are weaker.¶
If a CDNS shares a cache between its recursive resolver component and its forwarding component, any RR considered for caching from a forwarded response MUST undergo bailiwick checks that are at least as stringent as those defined for recursive resolution mode (Section 3.2.1 and Section 3.3).¶
Specifically, when a response is received from an upstream forwarder, and Q.NAME was part of a $Z_F$:¶
a. Q.ZONE for validating this response MUST NOT be assumed to be "." by default if the cache is shared.¶
b. Q.ZONE SHOULD be determined based on the specific $Z_F$ that Q.NAME matched, or based on knowledge of the upstream forwarder's authoritative scope if the forwarder is not a full recursive resolver itself.¶
c. If the upstream forwarder is a recursive resolver, the CDNS MAY rely on the upstream resolver's bailiwick checks ONLY IF the CDNS itself does not cache the response or if its caching is strictly partitioned from the recursive resolver's cache. If cached in a shared manner, the CDNS MUST re-validate.¶
To prevent the V1 vulnerability in CDNS, if Q.NAME is in $Z_F$
and Q.ZONE is determined (e.g., as $Z_F$ itself or an
ancestor), records in the authority and additional sections of
the response from the forwarder MUST be validated against this
Q.ZONE as per Section 3.3.2 and Section 3.3.3. For example, if $Z_F$
is corp.example.com and a query for printer.corp.example.com
is forwarded, the response MUST NOT be allowed to cache an NS
record for .com in the authority section if Q.ZONE was effectively
corp.example.com.¶
Some CDNS implement a fallback mechanism where if a forwarded query fails (e.g., timeout), the CDNS might attempt to resolve it recursively.¶
If a query originally intended for forwarding (in $Z_F$) falls back to recursive resolution, the recursive resolution process MUST determine its Q.ZONE and apply bailiwick checks independently, as per Section 3.2.1 and Section 3.3. It MUST NOT carry over any relaxed bailiwick assumptions from the failed forwarding attempt.¶
The enhanced bailiwick checking rules specified in this document are intended to mitigate several DNS cache poisoning attack vectors, particularly those identified in [MAGINOTDNS] that exploit ambiguities or weaknesses in current bailiwick implementations.¶
By requiring a more precise determination of Q.ZONE, especially in forwarding mode and within CDNS, these rules make it harder for an attacker to inject out-of-bailiwick NS records for parent zones (like TLDs) or unrelated zones. Stricter validation of authority and additional section records based on a correctly scoped Q.ZONE is key.¶
Proper CNAME chain validation with appropriate Q.ZONE adjustments at each step helps prevent attacks that leverage CNAMEs to introduce malicious data for the canonical target.¶
For CDNS, ensuring that data entering a shared cache from forwarding operations is subject to rigorous bailiwick checks equivalent to those in recursive mode is crucial to prevent cross-mode cache pollution.¶
While these measures significantly improve resilience against certain cache poisoning techniques, they do not replace the need for DNSSEC ([RFC4033], [RFC4034], [RFC4035]). DNSSEC provides cryptographic assurance of data origin and integrity and remains the most robust defense against cache poisoning. The rules in this document provide defense-in-depth and are particularly important for zones that are not DNSSEC-signed or for resolvers that do not validate DNSSEC signatures.¶
Implementation of these stricter rules may cause some currently accepted (but technically out-of-bailiwick) data from misconfigured authoritative servers to be rejected. This is generally desirable for security but operators should be aware of potential compatibility issues with non-compliant servers during rollout.¶
This document does not require any IANA actions.¶