DNSOP O. Surý Internet-Draft C. Vidal Updates: 1034, 1035 (if approved) E. Hunt Intended status: Standards Track Internet Systems Consortium Expires: 17 September 2026 16 March 2026 Parent-Centric Delegation Handling in DNS Resolvers draft-sury-dnsop-parent-centric-resolver-01 Abstract This document specifies a parent-centric behavioral model for DNS recursive resolvers, in which delegation decisions are always based on the NS RRset (or DELEG RRset) received from the parent side of a zone cut and are never overwritten by child-side NS data. The parent-centric model eliminates the "two sources of truth" problem inherent in the current DNS delegation design, closes the Ghost Domain and Phoenix Domain attack vectors, provides deterministic behavior in the presence of parent/child NS mismatches, and enables resolvers to safely accept sibling (out-of-bailiwick) glue by scoping delegation information to individual zone cuts. It also provides the behavioral foundation required for deployment of the DELEG extensible delegation mechanism. This document updates RFC 1034 and RFC 1035. Status of This Memo 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 17 September 2026. Surý, et al. Expires 17 September 2026 [Page 1] Internet-Draft Parent-Centric Resolver March 2026 Copyright Notice Copyright (c) 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Two Sources of Truth . . . . . . . . . . . . . . . . . . 5 2.2. Ghost Domain Attacks . . . . . . . . . . . . . . . . . . 5 2.3. Inconsistent RPZ Behavior . . . . . . . . . . . . . . . . 6 2.4. Impediment to DELEG Deployment . . . . . . . . . . . . . 6 2.5. Interaction with Strict Glue Checking . . . . . . . . . . 7 2.5.1. Why Strict Glue Was Necessary . . . . . . . . . . . . 8 2.5.2. How Parent-Centric Behavior Resolves This . . . . . . 9 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Core Behavioral Requirement . . . . . . . . . . . . . . . 9 3.2. Processing Referrals . . . . . . . . . . . . . . . . . . 10 3.3. Processing Authoritative Responses . . . . . . . . . . . 10 3.4. Answering Explicit NS Queries . . . . . . . . . . . . . . 11 3.4.1. Interaction with Minimal Responses . . . . . . . . . 12 3.4.2. NS Queries When Child-Side NS Is Not Cached . . . . . 12 3.5. Best Zone Cut Selection . . . . . . . . . . . . . . . . . 12 3.6. TTL and Expiration . . . . . . . . . . . . . . . . . . . 13 3.7. Delegation Information Replacement . . . . . . . . . . . 13 3.8. DELEG Integration . . . . . . . . . . . . . . . . . . . . 13 4. Interaction with Other Mechanisms . . . . . . . . . . . . . . 14 4.1. QNAME Minimization . . . . . . . . . . . . . . . . . . . 14 4.2. DNSSEC Validation . . . . . . . . . . . . . . . . . . . . 14 4.3. Delegation Limits . . . . . . . . . . . . . . . . . . . . 15 5. Operational Considerations . . . . . . . . . . . . . . . . . 15 5.1. Compatibility with Existing Infrastructure . . . . . . . 15 5.2. Impact on Responses to Recursive Clients . . . . . . . . 15 5.3. Zones with Differing Parent and Child NS Sets . . . . . . 16 5.4. Transition Considerations . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6.1. Elimination of Child-Side NS Overwrite Attacks . . . . . 17 Surý, et al. Expires 17 September 2026 [Page 2] Internet-Draft Parent-Centric Resolver March 2026 6.2. Mitigation of Ghost Domain and Phoenix Domain Attacks . . 17 6.2.1. Elimination of Cross-Delegation Glue Contamination . 18 6.2.2. Remaining Glue Trust Considerations . . . . . . . . . 18 6.3. Stable Delegation View . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 20 Appendix A. Rationale for Delegations in Positive Responses . . 21 Appendix B. Relationship to DELEG . . . . . . . . . . . . . . . 22 Appendix C. Intellectual Property Note . . . . . . . . . . . . . 23 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction The Domain Name System (DNS) [RFC1034] [RFC1035] uses NS (Name Server) records to delegate authority over portions of the namespace from a parent zone to a child zone. A fundamental consequence of the current delegation model is that NS records exist in two places: at the delegation point in the parent zone (the "parent-side" NS RRset) and at the apex of the child zone (the "child-side" or "apex" NS RRset). Historically, most recursive resolver implementations have followed a "child-centric" approach: when a referral is received from a parent zone, the resolver caches the parent-side NS RRset, but subsequently replaces it with the child-side apex NS RRset if one is observed in a response from the delegated zone. This replacement is performed on the assumption that the child zone's apex NS RRset is "more authoritative" than the parent's delegation point NS RRset. This document specifies a "parent-centric" behavioral model for recursive resolvers, in which delegation decisions are always based on the NS RRset (or DELEG RRset) received from the parent side of a zone cut, and are never overwritten by child-side NS data. The parent-centric model eliminates an entire class of inconsistency and security problems inherent in the child-centric approach. It also provides the behavioral foundation needed for the deployment of extensible delegation mechanisms such as the DELEG record [I-D.ietf-deleg]. This document does not prescribe any particular cache architecture, data-structure layout, or lookup ordering for implementations. Conforming implementations are free to use any internal organization -- including a single unified cache -- that achieves the required behavior. Surý, et al. Expires 17 September 2026 [Page 3] Internet-Draft Parent-Centric Resolver March 2026 1.1. Terminology 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. Parent-side NS RRset: The set of NS records present at a delegation point in the parent zone and optional glue records (A + AAAA) [RFC9471] required for the iterative clients to find the addresses of name servers that are contained within a delegated zone. These records are non-authoritative in the parent zone and are included in referral responses. Child-side NS RRset: The set of NS records present at the apex of the delegated (child) zone. These records are authoritative within the child zone. Delegation information: The data a resolver uses to determine which nameservers are responsible for a zone cut: nameserver names, associated addresses from the glue records, and (when DELEG [I-D.ietf-deleg] is supported) DELEG and DELEGPARAM parameters. This information originates from referral responses received from a parent zone's nameservers. Child-centric resolver: A resolver that replaces parent-side delegation information with child-side apex NS data when available. Parent-centric resolver: A resolver that retains parent-side delegation information as the authoritative source for delegation decisions and does not overwrite it with child-side NS data. Answer data: Resource records cached by the resolver for the purpose of answering client queries. In the context of this document, the child-side NS RRset is answer data: it is the authoritative answer to an NS query at a zone apex. Delegation data: Information used internally by the resolver to determine which nameservers to contact when resolving queries. In the context of this document, the parent-side NS RRset (and associated glue) is delegation data. Delegation data is never returned to clients as an answer. Surý, et al. Expires 17 September 2026 [Page 4] Internet-Draft Parent-Centric Resolver March 2026 2. Problem Statement 2.1. Two Sources of Truth [RFC1034] Section 4.2.1 specifies that NS records appear both at the delegation point in the parent zone and at the apex of the child zone. Ideally these two NS RRsets are identical, but in practice they frequently diverge. When a zone administrator updates the nameserver set, it is common for either the parent or the child NS RRset to be updated first, creating a window (sometimes indefinitely long) during which the two disagree. A child-centric resolver that replaces parent-side NS data with child-side NS data effectively trusts the child zone to define its own delegation. This creates several problems: * A compromised or misconfigured child zone can redirect resolution by publishing NS records pointing to servers not sanctioned by the parent. * NS RRsets learned from the child side may include nameservers that are not present at the delegation point, creating inconsistencies in the resolver's view of the namespace. Or NS RRsets learned from the child side may not include nameserver that are present at the delegation point, again creating inconsistencies in the resolver's view of the namespace. It is up to the implementation whether the two distinct sets of NS RRsets get merged or whether the child-side NS RRset replace the parent-side delegation information. * The child-side NS RRset may have a different (often longer) TTL than the parent-side delegation, causing the resolver to use stale delegation information. Alternative parent-side NS RRsets may have a different TTL than the child-side NS RRset. It is again up to the implementation whether the parent-side NS RRset TTL is honored, the child-side NS RRset TTL is honored or the smallest value of the two is chosen. 2.2. Ghost Domain Attacks The Ghost Domain attack [GHOST-DOMAIN] demonstrated that a child- centric resolver's willingness to replace cached delegation data with fresher child-side NS records allows an attacker to keep a revoked domain name resolvable indefinitely. The attack works by exploiting the cache update logic: even after the parent zone has removed the delegation, the attacker can trigger queries that cause the resolver to contact the (still-running) rogue nameserver, which returns a child-side NS RRset with a fresh TTL, overwriting the stale (or Surý, et al. Expires 17 September 2026 [Page 5] Internet-Draft Parent-Centric Resolver March 2026 absent) parent-side delegation data in the cache. Experiments showed that more than 70% of tested open resolvers were still resolving a revoked domain a week after removal from the parent zone at the time the research was published. The follow-up work on Phoenix Domain [PHOENIX-DOMAIN] showed that the original Ghost Domain mitigations (TTL capping on NS replacement) were insufficient. The Phoenix Domain attack uncovered additional vulnerable cache operations in the delegation process that allowed revoked domains to remain resolvable for over a month on more than 25% of tested resolvers at the time this research was published. Critically, the Phoenix Domain paper identifies the child-centric vs. parent-centric distinction as a key architectural factor: parent- centric resolvers that do not overwrite delegation data with child- side NS records are immune to the T1 class of Phoenix Domain attacks, because the attacker cannot inject fresh delegation data through child-zone responses. A parent-centric resolver as specified in this document eliminates the Ghost Domain and Phoenix Domain T1 attack vectors entirely, because delegation decisions are never influenced by child-side NS data. 2.3. Inconsistent RPZ Behavior Response Policy Zones (RPZ) [RFC7719] include NSDNAME and NSIP trigger types that match against the nameservers of the zone containing the answer. When a child-centric resolver replaces the parent-side NS RRset with the child-side NS RRset, the set of nameserver names and addresses visible to RPZ policy evaluation changes unpredictably depending on whether the child-side data has been cached yet. This leads to inconsistent policy enforcement: the same query may or may not trigger an RPZ rule depending on the cache state. A parent-centric resolver provides a stable set of delegation information for RPZ evaluation, because the delegation data used for resolution is always the parent-side data received in referrals, regardless of what child-side NS data may exist in the cache. 2.4. Impediment to DELEG Deployment The DELEG record [I-D.ietf-deleg] is an extensible delegation mechanism that is authoritative on the parent side of a zone cut. DELEG records can carry server addresses, transport parameters, and other extensible metadata directly in the delegation, eliminating the need for additional queries to resolve nameserver addresses. The companion DELEGPARAM record provides an indirection mechanism for Surý, et al. Expires 17 September 2026 [Page 6] Internet-Draft Parent-Centric Resolver March 2026 sharing delegation parameters across multiple zones. A child-centric resolver cannot cleanly support DELEG, because: * DELEG data is exclusively parent-side; there is no child-side equivalent. A child-centric resolver that overwrites parent-side data with child-side NS data would lose the DELEG information. * [I-D.ietf-deleg] Section 5.1.1 requires that when DELEG records exist at a delegation point, a DELEG-aware resolver MUST use the name servers from those DELEG records and MUST NOT use NS records for the zone, even if resolution using DELEG records has failed. A parent-centric resolver naturally enforces this rule because it never overwrites parent-side delegation data with child-side NS data. 2.5. Interaction with Strict Glue Checking Recent resolver releases have adopted strict (hardened) glue checking [STRICT-GLUE]: glue records in referral responses are only accepted when the NS target name is at or below the delegation point (in- domain glue). Glue for out-of-domain, but in-the-bailiwick nameserver names -- "sibling glue" -- is discarded, and those names must be resolved iteratively. For example, given the delegation from .org: example.org. NS ns1.example.org. example.org. NS ns2.otherdomain.org. ns1.example.org. A 198.51.100.42 ns2.otherdomain.org. A 203.0.113.53 strict glue checking accepts the A record for ns1.example.org (which is below example.org) but discards the A record for ns2.otherdomain.org (which is not). The resolver must then iteratively resolve ns2.otherdomain.org, following a separate delegation chain through the otherdomain.org zone. This strict checking revealed a misconfiguration where a set of domains used cyclic in-the-bailwick glue and relied on the relaxed acceptance of the glue records for resolution. For example, give the delegation from .org: Surý, et al. Expires 17 September 2026 [Page 7] Internet-Draft Parent-Centric Resolver March 2026 example.org. NS ns1.otherdomain.org. example.org. NS ns2.otherdomain.org. ns1.otherdomain.org. A 198.51.100.42 ns2.otherdomain.org. A 203.0.113.53 otherdomain.org. NS ns1.example.org. otherdomain.org. NS ns2.example.org. ns1.example.org. A 198.51.100.42 ns2.example.org. A 203.0.113.53 strict glue validation would throw away both set of glue records and make both example.org and otherdomain.org would fail to resolve. 2.5.1. Why Strict Glue Was Necessary In a child-centric resolver that stores all cached data in a shared namespace, sibling glue is dangerous because it can contaminate unrelated delegations. If a referral for example.org includes a glue A record for ns1.example.net, that record enters the shared cache and may be used when resolving names under example.net -- even though the glue was provided by the .org zone, which has no authority over example.net addresses. An attacker who controls a delegation in .org can exploit this to inject forged address records for nameservers in .net, effectively poisoning the resolution of unrelated zones. Strict glue checking prevents this cross-delegation contamination by rejecting all sibling glue. However, this strict policy causes significant operational problems: * When sibling glue is rejected, the resolver performs more iterative lookups, each of which traverses additional delegation chains. Any parent/child NS mismatch along those chains can cause resolution failures or inconsistent behavior. * In pathological cases, the combination of strict glue rejection and nested sibling delegations can produce resolution failures that succeed on retry (after intermediate records have been cached), making the problem intermittent and difficult to diagnose. * The increased query volume puts additional load on authoritative servers and increases resolution latency for end users. Surý, et al. Expires 17 September 2026 [Page 8] Internet-Draft Parent-Centric Resolver March 2026 2.5.2. How Parent-Centric Behavior Resolves This The parent-centric model eliminates the underlying security problem that strict glue checking was designed to address, because delegation information is self-contained per zone cut and is not shared across delegations. When a parent-centric resolver accepts sibling glue for ns1.example.net in a referral for example.org, that address is recorded as part of the example.org delegation information. It is used only when contacting servers for example.org and is never used when resolving names under example.net or any other zone. The delegation information for example.net is a separate entry, populated from referrals received from the .net zone's parent, and is completely unaffected by glue received in referrals for example.org. This scoping means that a parent-centric resolver can safely accept sibling glue again without risk of cross-delegation contamination. The operational problems caused by strict glue rejection -- increased query volume, resolution failures due to nested out-of-bailiwick delegations, and sensitivity to parent/child NS mismatches -- are avoided, because the sibling glue is used directly from the delegation information without requiring additional iterative resolution. Resolver implementations adopting the parent-centric model MAY therefore accept sibling glue from referral responses, provided that the glue is stored as part of the delegation information for the specific zone cut and is not used for any other purpose. 3. Specification 3.1. Core Behavioral Requirement A conforming resolver MUST use delegation information received from parent zones (via referral responses) as the basis for all delegation decisions. Delegation information MUST NOT be overwritten, replaced, or supplemented by child-side NS RRsets observed in authoritative responses from the delegated zone. This requirement applies regardless of how the resolver organizes its internal data structures. Any particular cache architecture, data- structure choice, or lookup strategy is an implementation detail and out-of-the-scope for this document. Surý, et al. Expires 17 September 2026 [Page 9] Internet-Draft Parent-Centric Resolver March 2026 3.2. Processing Referrals When a resolver receives a referral (a response with no answer, containing NS records in the authority section and optional glue in the additional section), it MUST process the delegation as follows: 1. Extract the zone cut name from the owner name of the NS RRset in the authority section. 2. Record the delegation information: the nameserver names from the NS RRset, and any A/AAAA glue records present in the additional section for those nameserver names. Because delegation information in the parent-centric model is scoped to the individual zone cut and is not shared across delegations, both in-domain glue and sibling glue can be safely accepted; see Section 2.5 for the security analysis. The effective TTL of the delegation information SHOULD be the minimum of the NS RRset TTL and the accepted glue record TTLs. 3. Use this delegation information for subsequent resolution of names under the zone cut, until it expires or is replaced by a newer referral for the same zone cut. The resolver MUST NOT use the referral NS RRset to respond to the ordinary DNS clients. The referral NS RRset is parent-side data and MUST be treated as delegation information only. 3.3. Processing Authoritative Responses When a resolver receives an authoritative response (AA bit set) that includes a child-side NS RRset (either in the answer section for an NS-type query, or in the authority section as part of the response), the resolver MUST cache the child-side NS RRset as answer data, subject to normal cache admission policies. This cached child-side NS RRset is used to answer explicit NS queries from clients (Section 3.4) but MUST NOT be used to update, replace, or supplement the delegation information used for delegation decisions. The child-side NS RRset is authoritative data from the child zone and is the correct answer to an NS query. The parent-side NS RRset received in referrals is non-authoritative delegation information and MUST NOT be returned as the answer to an NS query. Surý, et al. Expires 17 September 2026 [Page 10] Internet-Draft Parent-Centric Resolver March 2026 3.4. Answering Explicit NS Queries When a recursive resolver receives a query for the NS RRset at a zone name (QTYPE=NS, QNAME=), it MUST resolve and return the child-side (authoritative) NS RRset, not the parent-side delegation data. This is a fundamental distinction of the parent-centric model: parent-side NS data drives delegation decisions internally, but the child-side NS data is the authoritative answer to NS queries. The resolver processes this query through normal recursive resolution: 1. Using its delegation information, the resolver contacts an authoritative server for the queried zone. 2. The authoritative server returns the apex NS RRset with the AA (Authoritative Answer) flag set. 3. The resolver caches this child-side NS RRset as answer data and returns it to the client. The response to the client MUST accurately reflect the properties of the child-side NS data: AA flag: The child-side NS RRset is authoritative data from the child zone. When a resolver that is also configured as an authoritative server for the queried zone returns this data, it MUST set the AA flag. When a purely recursive resolver returns a cached child-side NS RRset, it SHOULD set the AA flag to indicate that the data originates from the authoritative child zone, distinguishing the response from a referral (which would contain parent-side NS data without the AA flag). This is consistent with the principle that the answer to an NS query at a zone apex is authoritative data, regardless of how the resolver obtained it. AD flag: If the child-side NS RRset has been DNSSEC-validated, the resolver SHOULD set the AD (Authenticated Data) flag in the response, subject to the normal AD flag rules ([RFC4035] Section 3.2.3 and [RFC6840] Section 5.8). DNSSEC validation of the child-side NS RRset provides the client with cryptographic assurance that the nameserver set is authentic, a property that parent-side delegation NS data (which is unsigned glue) can never provide. The resolver MUST NOT return the parent-side delegation NS data as the answer to an NS query under any circumstances. The parent-side data is non-authoritative and would provide the client with incorrect information about the zone's published nameserver set. Surý, et al. Expires 17 September 2026 [Page 11] Internet-Draft Parent-Centric Resolver March 2026 Note that the child-side NS RRset returned to the client may differ from the parent-side NS RRset used for delegation. This is expected and correct: the two serve different purposes. The child-side NS is the zone's own statement of its nameservers (answer data), while the parent-side NS is the parent's statement of which servers are delegated (delegation data). 3.4.1. Interaction with Minimal Responses When QNAME minimization [RFC9156] is enabled (as RECOMMENDED for cached responses in Section 5.2), the resolver omits the NS RRset from the authority section of non-NS-type responses. This has no effect on explicit NS queries: when the client queries for NS records specifically, the full child-side NS RRset is returned in the answer section regardless of the minimal responses setting. 3.4.2. NS Queries When Child-Side NS Is Not Cached If the resolver receives an NS query for a zone name and does not have the child-side NS RRset cached, it MUST resolve the query through normal recursion (contacting the zone's authoritative servers) rather than returning the parent-side delegation data from its delegation information. The parent-side data is not a valid answer to an NS query. 3.5. Best Zone Cut Selection When a resolver needs to determine the closest enclosing zone cut for a query name (the "best zone cut"), it MUST select among the following sources in this order of preference: 1. Locally configured zones: forward zones, stub zones, static-stub zones, and other policy-configured delegations. 2. Delegation information learned from referrals, as described in Section 3.2. 3. Root hints, if no other delegation information is available. When both a locally configured zone and referral-learned delegation information exist for overlapping names, the more specific (closer to the query name) delegation is preferred, with the exception that static-stub zones always take precedence over referral-learned delegations at the same name. Child-side NS RRsets cached from authoritative responses (Section 3.3) MUST NOT be considered when selecting the best zone cut. Surý, et al. Expires 17 September 2026 [Page 12] Internet-Draft Parent-Centric Resolver March 2026 3.6. TTL and Expiration Delegation information learned from referrals is subject to TTL-based expiration. The TTL is computed as described in Section 3.2. Expired delegation information MUST NOT be used for delegation decisions; the resolver MUST fall back to the next available delegation source (a less specific referral-learned delegation, a locally configured zone, or root hints). Implementations SHOULD NOT apply neither a minimum TTL floor or a maximum TTL ceiling to delegation information that differs from the floor applied to cached answer data, as the two serve different purposes and have different operational characteristics. The implementations MAY have a seperate configuration options to apply the limits to the TTL received for the delegation information. 3.7. Delegation Information Replacement When a resolver receives a new referral for a zone cut for which it already holds unexpired delegation information, the new referral replaces the existing delegation information. This ensures that the resolver tracks changes in the parent zone's delegation. A resolver MUST NOT merge delegation information from multiple referrals for the same zone cut. Each referral provides a complete delegation, and the most recently received delegation supersedes any previous one. 3.8. DELEG Integration When a resolver supports the DELEG record [I-D.ietf-deleg], delegation information for a zone cut may include DELEG parameters (server addresses, server names, DELEGPARAM references, transport parameters) in addition to or instead of NS-based delegation data. A conforming resolver that receives a referral containing DELEG records at a zone cut MUST use the DELEG-based delegation information to populate its delegation information (per [I-D.ietf-deleg] Section 5.1.3 and Section 5.1.4) and MUST NOT use NS records for that zone, even if DELEG-based resolution fails (per [I-D.ietf-deleg] Section 5.1.1). The parent-centric model naturally accommodates DELEG because: * DELEG data is exclusively parent-side and arrives in referrals, which is exactly the data the parent-centric resolver trusts. Surý, et al. Expires 17 September 2026 [Page 13] Internet-Draft Parent-Centric Resolver March 2026 * DELEG records can carry server addresses directly (via server-ipv4 and server-ipv6 parameters), eliminating the need for glue records and the associated trust questions. DELEGPARAM records can provide an additional layer of indirection for shared delegation configurations. * DELEG records are signed on the parent side, enabling DNSSEC validation of delegation parameters -- a capability fundamentally impossible with unsigned parent-side NS records. 4. Interaction with Other Mechanisms 4.1. QNAME Minimization QNAME minimization [RFC9156] relies on knowing the current best zone cut in order to construct minimized queries. A parent-centric resolver provides more reliable zone cut information for QNAME minimization because the delegation data used for zone cut determination is never polluted by child-side NS data that might indicate a different (and potentially incorrect) zone boundary. When resuming QNAME minimization after receiving a referral, the resolver uses the updated delegation information as the basis for subsequent minimized queries. 4.2. DNSSEC Validation Parent-side NS records are not signed (they are glue), so delegation information learned from NS-based referrals is not directly DNSSEC- validated. This is consistent with current practice: even child- centric resolvers use unsigned referral NS data to locate authoritative servers. The DNSSEC chain of trust for a delegated zone is established through DS records, which are authoritative on the parent side and are validated normally. The parent-centric model does not change DS record processing. When DELEG records are deployed (Section 3.8), the delegation parameters are signed on the parent side and can be validated as part of the delegation. This provides a cryptographic binding between the delegation parameters and the parent zone's DNSSEC chain -- a significant security improvement over the current unsigned NS-based delegation model. Surý, et al. Expires 17 September 2026 [Page 14] Internet-Draft Parent-Centric Resolver March 2026 4.3. Delegation Limits Resolvers typically impose a limit on the number of nameservers or addresses they will process from a single delegation, to prevent excessive resource consumption from very large delegations. The parent-centric model preserves this limit. Implementations SHOULD make this limit configurable with a reasonable default (e.g., 26). Q?: is 2 * 13 good number? 5. Operational Considerations 5.1. Compatibility with Existing Infrastructure The parent-centric model is fully compatible with the existing DNS infrastructure. No changes are required to authoritative servers, registries, registrars, or stub resolvers. The change is entirely within the recursive resolver's internal processing. This approach has been deployed in production by multiple resolver implementations, including Nominum Vantio and Google Public DNS, without causing widespread operational issues. More implementations here??? 5.2. Impact on Responses to Recursive Clients A child-centric resolver that has both parent-side and child-side NS data may include the child-side NS in the authority section of responses to recursive clients (when minimal responses option is disabled). A parent-centric resolver that does not use child-side NS data for delegation has no reason to look up the child-side NS RRset during resolution; therefore, the child-side NS may not be readily available for inclusion in the authority section. Implementations adopting the parent-centric model SHOULD treat recursive responses served from the cache as if minimal response option is enabled, omitting the NS RRset from the authority section. This is consistent with modern best practice, reduces response size, and avoids the need to perform additional lookups solely for populating the authority section. This only affects responses served from the cache by a recursive resolver. Authoritative responses (where the server is authoritative for the queried zone) are not affected by this change. Surý, et al. Expires 17 September 2026 [Page 15] Internet-Draft Parent-Centric Resolver March 2026 TODO: I am actually not sure if this is a correct mechanism or not :shrug:. Alternative proposal below, but since this only impact the partial forwarders, I would say - it is a reasonable compromise to make... When a recursiver resolver receives a query with RD flag not set (RD=0) for the NS RRset at a zone name (QTYPE=NS, QNAME=), it MUST resolve and return the parent-side (delegation) NS RRset, not the child-side (authoritative) NS RRset. There might be downstream forwarding resolvers (e.g. DNS resolver using this resolver for DNS resolution). Returning child-side NS RRset is generally not a problem when the downstream DNS resolver is configured to do the forwarding for the whole DNS tree, but there might be configurations where the forwarding is configured only for certain parts of the DNS tree and the downstream DNS forwarder need to receive the parent-side delegation information. 5.3. Zones with Differing Parent and Child NS Sets Some zones intentionally maintain different NS RRsets at the parent and child, for example to include "stealth" nameservers in the child- side NS RRset that are not registered at the parent. Under the parent-centric model, these stealth nameservers will not be used for delegation decisions. This is the intended and correct behavior: the parent zone is the authority for delegation, and nameservers not listed in the parent's delegation are not part of the delegation. Also this behavior was already breaking the existing DNS standards, the parent-side and child-side NS RRset is supposed to be in sync. The child-side NS RRset remains available for answering explicit NS queries (Section 3.4) and for any purpose other than delegation decisions. Clients that query for the NS RRset at a zone apex will receive the child-side NS data (with the AA flag set), which may include nameservers not present in the parent-side delegation. This makes the difference between the two NS sets visible and auditable by zone operators. 5.4. Transition Considerations Resolver operators transitioning from a child-centric to a parent- centric implementation should be aware of the following: * After the transition, responses to queries with RD=1 may no longer include NS records in the authority section for cached answers. Monitoring systems that check for the presence of authority- section NS records in recursive responses should be updated. Surý, et al. Expires 17 September 2026 [Page 16] Internet-Draft Parent-Centric Resolver March 2026 * Zones that rely on child-side NS records to "override" the parent's delegation (e.g., to work around stale delegation data at a registry) will no longer benefit from this override. Such zones should instead update their parent-side delegation. * RPZ rules that were tuned based on child-side NS data may need to be reviewed, as the nameserver set visible to RPZ evaluation will be the (more stable) parent-side set. * Resolver implementations that have previously deployed strict glue checking (rejecting sibling glue) may relax this restriction after adopting the parent-centric model, because delegation information is scoped per zone cut and sibling glue can no longer contaminate unrelated delegations (see Section 2.5). Accepting sibling glue again reduces the number of iterative queries needed to resolve out-of-bailiwick delegations and avoids the resolution failures associated with strict glue rejection. 6. Security Considerations 6.1. Elimination of Child-Side NS Overwrite Attacks The most significant security benefit of the parent-centric model is that a compromised or malicious child zone cannot redirect resolution by publishing rogue NS records at its apex. Since the resolver never uses child-side NS data for delegation decisions, such attacks are ineffective. This closes an attack vector that has been present in child-centric resolvers since the inception of the DNS: an attacker who compromises only the child zone (but not the parent) can add NS records pointing to attacker-controlled servers, and a child-centric resolver will follow those NS records for subsequent queries. 6.2. Mitigation of Ghost Domain and Phoenix Domain Attacks As discussed in Section 2.2, the Ghost Domain [GHOST-DOMAIN] and Phoenix Domain [PHOENIX-DOMAIN] attacks exploit the child-centric cache update logic to keep revoked domain names resolvable. A parent-centric resolver is immune to the T1 class of these attacks because: * It does not accept child-side NS RRsets as delegation data, so an attacker cannot refresh a stale or removed delegation by responding with a child-side NS RRset carrying a new TTL. Surý, et al. Expires 17 September 2026 [Page 17] Internet-Draft Parent-Centric Resolver March 2026 * Once the parent-side delegation information expires (or is never received because the parent has removed the delegation), the resolver falls back to the next enclosing zone cut or root hints, which will not lead to the revoked zone. The T2 class of Phoenix Domain attacks (which exploits protocol-level TTL semantics in referral responses from still-delegated parent zones) is not fully addressed by the parent-centric model alone, but the attack surface is significantly reduced because the resolver maintains a clear separation between delegation data and answer data. 6.2.1. Elimination of Cross-Delegation Glue Contamination In a child-centric resolver with a shared cache, the primary risk of sibling glue is cross-delegation contamination: an A/AAAA record for ns1.example.net received in a referral for example.org enters the shared cache and can be used when resolving example.net, even though the glue was provided by the .org zone which has no authority over example.net addresses. This is the attack vector that strict glue checking [STRICT-GLUE] was designed to prevent. In the parent-centric model, delegation information is self-contained per zone cut. Glue received in a referral for example.org is part of the example.org delegation and is used only for contacting servers for that zone. It has no effect on the delegation information for example.net or any other zone. This scoping eliminates the cross- delegation contamination vector entirely, without the operational cost of discarding sibling glue. A parent-centric resolver can therefore safely accept sibling glue from referral responses (see Section 2.5), recovering the operational benefits of sibling glue (fewer iterative queries, faster resolution, tolerance of out-of-bailiwick delegation configurations) while maintaining security against cross-delegation poisoning. 6.2.2. Remaining Glue Trust Considerations Even with per-delegation scoping, glue records are still non- authoritative data that can be forged by an on-path attacker between the parent zone's authoritative server and the resolver. A forged glue record would cause the resolver to contact an attacker- controlled server for the specific delegation that received the forged glue. This risk is identical to the existing risk of forged referral responses and is mitigated by the same mechanisms (source port randomization, DNS cookies, DNSSEC validation of the subsequent responses from the delegation). Surý, et al. Expires 17 September 2026 [Page 18] Internet-Draft Parent-Centric Resolver March 2026 When DELEG records are used, server addresses included directly in the DELEG RDATA are signed on the parent side, providing DNSSEC- validated address information. This eliminates the glue trust problem entirely for DELEG-aware delegations, as the addresses are authenticated data rather than unsigned glue, and out-of-bailiwick resolution of nameserver names is no longer necessary. 6.3. Stable Delegation View By ensuring that delegation decisions are always based on parent-side data, the parent-centric model provides a more stable and predictable view of the delegation hierarchy. This stability benefits security mechanisms that depend on knowing the authoritative server set, including RPZ, DNS firewall policies, and logging/auditing systems. 7. IANA Considerations This document has no IANA actions. 8. Implementation Status *Note to the RFC Editor:* Please remove this section before publication. The parent-centric resolver behavior described in this document has been implemented in BIND 9 as part of a resolver refactoring. The implementation ensures that delegation decisions are based on referral-learned data rather than child-side NS RRsets from the cache. The fetch context uses a delegation set abstraction (containing nameserver names, IPv4/IPv6 addresses, and DELEG/ DELEGPARAM parameters) instead of raw NS rdatasets throughout the resolution process. The implementation passes the full BIND 9 system test suite with adjustments to tests that previously depended on child-side NS records appearing in the authority section of recursive responses. The parent-centric approach has also been deployed in production by Google Public DNS and was previously used by Nominum Vantio. More implementations? 9. References 9.1. Normative References Surý, et al. Expires 17 September 2026 [Page 19] Internet-Draft Parent-Centric Resolver March 2026 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, . [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and Implementation Notes for DNS Security (DNSSEC)", RFC 6840, DOI 10.17487/RFC6840, February 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9156] Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query Name Minimisation to Improve Privacy", RFC 9156, DOI 10.17487/RFC9156, November 2021, . [RFC9471] Andrews, M., Huque, S., Wouters, P., and D. Wessels, "DNS Glue Requirements in Referral Responses", RFC 9471, DOI 10.17487/RFC9471, September 2023, . 9.2. Informative References [GHOST-DOMAIN] Jiang, J., Liang, J., Li, K., Li, J., Duan, H., and J. Wu, "Ghost Domain Names: Revoked Yet Still Resolvable", In Proceedings of the Network and Distributed System Security Symposium (NDSS 2012), February 2012, . Surý, et al. Expires 17 September 2026 [Page 20] Internet-Draft Parent-Centric Resolver March 2026 [I-D.ietf-deleg] Špaček, P., Weber, R., and Lawrence, "Extensible Delegation for DNS", Work in Progress, Internet-Draft, draft-ietf-deleg-07, 6 February 2026, . [PHOENIX-DOMAIN] Li, X., Liu, B., Bai, X., Duan, H., Li, Q., and Q. Pan, "Ghost Domain Reloaded: Vulnerable Links in Domain Name Delegation and Revocation", In Proceedings of the Network and Distributed System Security Symposium (NDSS 2023), February 2023, . [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015, . [STRICT-GLUE] Internet Systems Consortium, "Operational Notification: Impact of Stricter Glue Checking", December 2025, . Appendix A. Rationale for Delegations in Positive Responses During implementation, the question arose of whether delegation information should also be recorded when it appears in positive authoritative responses (AA set) rather than only in referrals. Consider the following zone structure: zone nameserver ---- ---------- example ns1 foo.example ns2 bar.foo.example ns2 To resolve a.bar.foo.example, the resolver: 1. Asks a root server for example, receives a referral to ns1. 2. Asks ns1 for foo.example, receives a referral to ns2. 3. Asks ns2 for bar.foo.example/NS, receives a positive authoritative answer (AA set) with the NS in the answer section. Surý, et al. Expires 17 September 2026 [Page 21] Internet-Draft Parent-Centric Resolver March 2026 If the delegation from step 3 is not recorded, the closest zone cut known to the resolver is foo.example, which still works because ns2 is authoritative for both foo.example and bar.foo.example. However, not recording this delegation means the resolver will not have address information for bar.foo.example nameservers available, so additional section data in subsequent responses may be incomplete. Whether this trade-off is acceptable depends on the deployment context and whether minimal responses options is in use. Implementations MAY choose to record delegation information learned from positive authoritative responses, but SHOULD carefully evaluate the impact on query volume and consistency. Appendix B. Relationship to DELEG The DELEG record [I-D.ietf-deleg] defines an extensible delegation mechanism that is exclusively parent-side. The parent-centric resolver behavior described in this document provides the necessary behavioral foundation for DELEG support: * Delegation information as defined in this document naturally accommodates DELEG data alongside or instead of NS-based delegations. * Each delegation can contain DELEG entries with embedded server addresses (server-ipv4, server-ipv6), server names (server-name), and DELEGPARAM references (include-delegparam), in addition to traditional NS names and glue. * When DELEG records are present at a delegation point, the parent- centric model provides a natural enforcement point for the rule from [I-D.ietf-deleg] Section 5.1.1 that a DELEG-aware resolver MUST use name servers from DELEG records and MUST NOT fall back to NS records. * Because DELEG is signed on the parent side, a parent-centric resolver can validate delegation parameters through the normal DNSSEC chain of trust -- a capability that is fundamentally impossible with unsigned parent-side NS records. The parent-centric behavioral model is a prerequisite for correct DELEG implementation. A child-centric resolver that overwrites parent-side delegation data with child-side NS data would lose the DELEG information and could not maintain the invariant that DELEG takes precedence over NS. Surý, et al. Expires 17 September 2026 [Page 22] Internet-Draft Parent-Centric Resolver March 2026 Appendix C. Intellectual Property Note *Note to the RFC Editor:* Please remove this appendix before publication. The authors are aware of U.S. Patent 7,769,826 ("Systems and methods of providing DNS services using separate answer and referral caches", filed June 26, 2003, assigned to Nominum, Inc., now held by Akamai Technologies). That patent claims a specific cache architecture in which answer information and referral information are stored in separate data structures (a flat/hash table for answers and a hierarchical/tree structure for referrals) with a particular lookup order and classification-based routing of responses to the appropriate store. This document intentionally does not specify, recommend, or require any particular cache architecture, data-structure choice, lookup ordering, or response classification scheme. It specifies only the behavioral requirement that delegation decisions be based on parent- side NS (or DELEG) data from referrals and not be overwritten by child-side NS data. Conforming implementations are free to use any internal organization -- including a single unified cache -- that achieves the required behavior. The authors believe that this document is not Covered by the above mentioned patent. Acknowledgements The concept of parent-centric delegation handling has been explored by multiple DNS implementations over the years. The authors would like to acknowledge the prior work by Nominum (Vantio) and Google (Public DNS) in deploying parent-centric resolvers at scale, which demonstrated the viability of this approach. The BIND 9 implementation was developed by Colin Vidal with contributions from Evan Hunt and Ondřej Surý, building on the issue analysis by Petr Špaček. Authors' Addresses Ondřej Surý Internet Systems Consortium Czechia Email: ondrej@isc.org Surý, et al. Expires 17 September 2026 [Page 23] Internet-Draft Parent-Centric Resolver March 2026 Colin Vidal Internet Systems Consortium France Email: colin@isc.org Evan Hunt Internet Systems Consortium United States of America Email: each@isc.org Surý, et al. Expires 17 September 2026 [Page 24]