Signer-Zone Containment for DNSSEC Wildcard Validation Palo Alto Networks
qzhang@paloaltonetworks.com
 Purdue University
shen624@purdue.edu
 The University of Texas at Dallas
imtiaz.karim@utdallas.edu
 Purdue University
bertino@purdue.edu
 Palo Alto Networks
dpliu@paloaltonetworks.com
 University of California, Irvine
zhou.li@uci.edu
 Operations and Management DNSSECwildcardRRSIG Validators for the DNS Security Extensions (DNSSEC) reconstruct the original owner name of a signed resource record set (RRset) using the RRSIG Labels field. If the reconstructed owner is outside the signing zone, a cryptographically correct signature can be misinterpreted as authenticating wildcard data belonging to another zone. Aggressive use of DNSSEC-validated caches can extend the effect to other names. This document updates RFC 4035 to require signer-zone containment of the reconstructed owner and updates RFC 8198 to preserve that authenticated relationship when reusing wildcard data. These requirements constrain DNSSEC authentication and cached reuse. They do not change DNS wildcard matching or synthesis rules, or DNS message formats.
Introduction The RRSIG Labels field allows a validator to reconstruct the original signed owner name, including when a received owner results from wildcard expansion. Its definition in and the reconstruction algorithm in allow a validator to recover the owner name that was used to generate a signature. The checks in also require the Signer's Name to identify the zone containing the RRset. The relationship between that signing zone and the reconstructed owner needs to be checked explicitly. A signature over a reconstructed owner outside the signing zone does not establish authority for data at that owner, even when the received owner is within the signing zone and cryptographic verification succeeds. Reusing such data as a wildcard source under can cross a zone boundary. The DNSSECVerif study identified this interaction . Public implementation reports are summarized in . This document adds a containment check to the validation procedure in RFC 4035 and specifies which authenticated information must remain associated when RFC 8198 reuses wildcard data. The requirements apply to each RRSIG considered for validation. They retain the existing distinction between authenticating a wildcard source and proving that the source applies to a particular query name. The correction is deliberately limited to reconstructed-owner containment and its preservation during wildcard reuse. It leaves the wildcard matching and synthesis rules described in unchanged, including expansion over more than one label. It does not change denial-of-existence algorithms, trust-anchor processing, or DNSSEC algorithm policy. For a signing-zone apex whose leftmost label is not an asterisk, the added containment check requires the RRSIG Labels value to be at least the number of non-root labels in that apex, in addition to the existing authority and upper-bound checks. The exact-name exception for an asterisk-named apex is described in ; gives the conditional count-based formulation.
Conventions and 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 when, and only when, they appear in all capitals, as shown here. DNS terminology follows . Wildcard domain name, closest encloser, and source of synthesis have the meanings in . This document uses the following notation for one candidate RRSIG and the RRset it covers:
O:
The received RRset owner name.
S:
The Signer's Name in the candidate RRSIG.
L:
The value of the candidate RRSIG Labels field.
N:
The number of non-root labels in O, including any label whose contents are an asterisk.
R:
The original owner name reconstructed from O and L by the algorithm in Section 5.3.2 of RFC 4035.
A name is a strict subdomain of another name if it has that name as a suffix of complete labels and has at least one additional label. The root name has zero non-root labels. A wildcard label is a label consisting of the single octet 0x2a; an asterisk within a longer label is not a wildcard label. For clarity, the existing reconstruction yields R = O when L = N. When L is less than N, R consists of a wildcard label followed by the rightmost L labels of O; for L = 0 this yields the name "*.". L greater than N fails an existing validation check. Although L omits an original owner's leftmost wildcard label, N counts all non-root labels in the received owner.
Problem Description Consider a signed child zone, child.example., and a received RRset at a.child.example. A candidate RRSIG names child.example. as S but sets L to 1. The reconstruction algorithm yields R = *.example. The child-zone key can sign the corresponding octets, but authority over child.example. does not confer authority over *.example. By contrast, the same received owner with S = child.example. and L = 2 reconstructs *.child.example. and passes containment. That source can also synthesize an owner such as a.b.child.example. when the existing wildcard-applicability rules permit it. The new check does not limit a wildcard to matching a single label. A validator that checks only the received owner's relationship to S and verifies the signature can lose this distinction. If a cache then indexes the RRset as wildcard data at *.example., the child signature can be reused as if it authenticated data in the parent zone. Suitable denial-of-existence data used in a later synthesis does not repair the missing authorization for the wildcard source. The check is also needed when an implementation considers multiple signatures. Validation of the RRset using one RRSIG does not authenticate a different RRSIG's Labels or Signer's Name. Using the validation result from one signature with the reconstruction metadata from another can recreate the same error.
Evidence from Deployed Resolvers Public vendor reports document practical consequences of insufficient RRSIG Labels validation in deployed resolver software:
  • BIND 9: CVE-2026-11721 describes reconstruction of a wildcard name above an attacker-controlled zone, with potential cache poisoning when DNSSEC-based synthesis is enabled with synth-from-dnssec yes .
  • Unbound: CVE-2026-44690 describes insufficient Labels validation combined with premature cache writes during aggressive NSEC processing. Its documented attack uses a delegated zone beneath an NSEC-signed parent to poison sibling-zone data. The reported fixes address Labels validation, cache-write ordering, and wildcard bailiwick checks .
  • PowerDNS Recursor: CVE-2026-52688 describes a DNSSEC wildcard-validation bypass caused by a crafted authoritative reply with too few RRSIG labels .
  • Knot Resolver: the 6.4.1 release notes document a correction for RRSIG Labels values below the label count of the RRSIG Signer's Name, affecting primarily the aggressive cache. That release entry gives no CVE identifier for this correction .
The reported prerequisites and consequences differ across implementations. These reports motivate explicit containment and cache-association requirements; they do not establish identical defects or conformance of the published fixes to all requirements in this document.
Updates to Validation and Wildcard Reuse
Update to RFC 4035: Reconstructed Owner Containment The following requirements are added to Section 5.3.2 of , immediately after the algorithm that calculates the owner name used in the signed data:
For each candidate RRSIG, the validator MUST check that the reconstructed original owner name is either equal to or a strict subdomain of the RRSIG Signer's Name. If the reconstructed original owner name differs from the received RRset owner name, it MUST be a strict subdomain of the RRSIG Signer's Name. These comparisons MUST operate on complete DNS labels, using the DNS case-insensitive comparison rules in . A textual suffix comparison that does not respect label boundaries is insufficient. An RRSIG that fails either containment requirement MUST NOT be used to authenticate the received RRset or a wildcard source reconstructed from it. An implementation can perform these checks before cryptographic verification; successful cryptographic verification does not override a failed check.
These requirements supplement the existing checks in Section 5.3.1 of RFC 4035. In particular, containment of names does not by itself establish that a key is authenticated or that the signing zone is authoritative for the RRset. Existing zone-cut rules, including the treatment of parent-side DS RRsets, continue to apply. A failure is associated with the candidate RRSIG, not unconditionally with every signature covering the RRset. Processing of alternative signatures and determination of the final validation result continue to follow . An otherwise valid signature can still authenticate the RRset when another candidate signature fails these checks. The requirement for a strict subdomain when R differs from O prevents use of an asterisk-named zone apex as a source of synthesis. The added check does not reject data at that exact apex; see .
Update to RFC 8198: Authenticated Wildcard Source Append the following text to Section 5.3 of :
Before a validator uses a cached RRset as a wildcard source for synthesis, it MUST establish that the source RRset data, the original owner name identifying that source, and the signing zone were authenticated together by successful validation of an RRSIG under RFC 4035 as updated by this document. The source owner name MUST be a strict subdomain of that signing zone's apex. A successful validation result for an RRset MUST NOT be used to authenticate an original owner name or signing-zone association obtained solely from a different RRSIG that did not successfully validate. Each wildcard-source association used for synthesis MUST be justified by a successfully validated RRSIG for that association. An implementation MUST preserve sufficient validated information to establish this association, or re-establish it by validation before use. It need not retain a particular cache representation or perform cryptographic verification on every cache hit. Information retained without the required association, including information retained across a software upgrade, MUST NOT be used for wildcard synthesis unless the association is established.
Authentication of a wildcard source means authenticating the RRset at its reconstructed original owner R, including the signing key's authority, signature validity, and the binding to signing zone S. This is distinct from accepting the received expanded answer at O when O differs from R. These requirements do not require successful validation of the complete incoming expanded response as a prerequisite for retaining independently authenticated source data. They also do not permit that source to answer a query without the applicable authenticated denial-of-existence proofs. When the cache lacks sufficient authenticated information for synthesis, the resolver follows the fallback to authoritative resolution specified in Section 5 of RFC 8198. All other requirements of RFC 8198 continue to apply, including the required denial-of-existence proofs and restrictions at zone cuts. NSEC and NSEC3 processing continues to follow RFC 4035, , and their applicable updates. Existing TTL and signature-validity limits, including the changes in , are unchanged.
Compatibility and Deployment
Ordinary Names and Wildcard Expansion Under , the closest encloser is an existing name in the selected zone, and the source of synthesis is its immediate asterisk child. A source used for synthesis therefore lies strictly below that zone's apex. The added check applies this existing authority boundary to the original owner recovered during DNSSEC validation. For a received RRset with neither wildcard expansion nor a wildcard owner name, L = N and the reconstructed owner is unchanged. For a legitimate wildcard expansion, the source lies within the authenticating zone and below its apex. Neither case requires a change to the DNS wire format, authoritative data, or correctly generated signatures. For example, if child.example. does not exist and example. is the closest encloser, *.example. can synthesize a.child.example. A signature with S = example. and L = 1 reconstructs that source and passes containment. The failing example in instead names child.example. as the signer of the same reconstructed source. Rejecting that candidate signature does not prohibit the legitimate parent-zone expansion. Compatibility here concerns correctly signed, standards-conforming wildcard synthesis. It does not require a validating resolver and a nonvalidating resolver to return the same result for an authentication-invalid response; DNSSEC validation-failure handling continues to follow RFC 4035. The checks apply whether or not aggressive use of DNSSEC-validated caches is enabled. Disabling aggressive wildcard synthesis alone does not implement the update to RFC 4035. A validator that stores wildcard-source associations in more than one cache or processing path needs to enforce the association requirement in each path that can later supply a source for synthesis.
Asterisk-Named Zone Apexes permits a zone apex whose leftmost label is an asterisk. For example, the zone *.example. can contain an RRset at its apex. Its RRSIG can have S = *.example. and L = 1. With O = *.example., reconstruction yields R = O = S. This exact-name case satisfies the containment requirement. Although L is less than N, R equals O; the label-count inequality alone does not distinguish this exact-name case from expansion. This example addresses the added containment check, rather than constituting a complete validation procedure. That apex is not a wildcard source for synthesis. A received owner x.*.example. with the same S and L would reconstruct the same R but would have R different from O; it therefore fails the strict-subdomain requirement. By contrast, a wildcard source at *.*.example. lies strictly below the apex *.example. and can satisfy the new checks. Consequently, an unconditional comparison requiring L to be at least the number of all non-root labels in S is not equivalent to the requirements in this document. Such a comparison would reject the valid exact-apex example. gives a conditional count-based formulation.
Other Validation and Response Processing The update does not change handling of the AD or CD bits, DNSSEC validation-failure responses, or retry behavior. It does not change whether a particular wildcard applies to a query name. Authenticated closest-encloser and next-closer evidence, NSEC3 Opt-Out constraints where applicable, and delegation boundaries remain governed by the existing specifications. The containment test does not replace the special authority rules for DS RRsets. For example, a DS RRset at child.example. signed by example. can satisfy the new check with R = O = child.example.; it is then evaluated using the existing parent-side DS rules.
Security Considerations The purpose of these requirements is to prevent a key authenticated for one zone from being treated as authenticating wildcard-source data outside that zone. Cryptographic possession of a valid child-zone key does not authorize the holder to supply wildcard data in its parent zone. A separate authentic denial proof cannot supply the missing authentication of that source. The per-signature checks and cache association requirements prevent two related failures: accepting an out-of-zone reconstructed owner directly, and assigning trusted status to unvalidated wildcard metadata after another signature has authenticated the RRset. Implementations need to apply the same association rules when inserting, merging, replacing, or recovering cached source data. These checks do not protect against malicious data signed by a key that is legitimately authoritative for the source, compromised trust anchors, or errors in other validation procedures. They do not expand the scope of wildcard synthesis or the lifetime of cached data.
IANA Considerations This document has no IANA actions.
Normative References Key words for use in RFCs to Indicate Requirement Levels Resource Records for the DNS Security Extensions Protocol Modifications for the DNS Security Extensions Domain Name System (DNS) Case Insensitivity Clarification The Role of Wildcards in the Domain Name System DNS Security (DNSSEC) Hashed Authenticated Denial of Existence Clarifications and Implementation Notes for DNS Security (DNSSEC) Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words Aggressive Use of DNSSEC-Validated Cache NSEC and NSEC3: TTLs and Aggressive Use Informative ReferencesCVE-2026-11721: Cache poisoning possible with label count discrepancy, RRSIG, and wildcardsInternet Systems Consortium Unbound security advisory: CVE-2026-44690NLnet Labs PowerDNS Recursor: CVE-2026-52688PowerDNS Knot Resolver 6.4.1 Release NotesCZ.NIC DNS Terminology Mind the Gap: Cross-RFC Formal Analysis Exposes DNSSEC's Hidden VulnerabilitiesAccepted manuscript, ACM CCS 2026
Validation Examples These examples test only the reconstructed-owner requirements. "Pass" does not mean that the RRset or a synthesized response is Secure: key authentication, authority, signature verification, time limits, and any necessary denial proofs must also succeed. All names are absolute. Owner reconstruction and containment
OSLRResult
a.c.example.c.example.3a.c.example.Pass
a.c.example.c.example.2*.c.example.Pass
a.b.c.example.c.example.2*.c.example.Pass
a.c.example.example.1*.example.Pass
a.c.example.c.example.1*.example.Fail
a.c.example.c.example.0*.Fail
a.c.example.c.example.4--Fail (existing)
*.c.example.c.example.2*.c.example.Pass
*.example.*.example.1*.example.Pass (exact)
x.*.example.*.example.1*.example.Fail
x.*.example.*.example.2*.*.example.Pass
..0.Pass
host..0*.Pass
child.example.example.2child.example.Pass (DS)
The root-wildcard example illustrates the name relationship only and asserts no current root-zone contents or operational policy. The exact asterisk-apex example cannot supply a source of synthesis. Additional regression cases should cover DNS case-insensitive equality, label-boundary comparisons, an out-of-zone received owner rejected by existing authority checks, and the following cache and signature interactions:
  • A valid ordinary signature plus an invalid wildcard-reconstruction signature: the ordinary RRset can validate, but the second signature does not create a trusted wildcard source.
  • A valid wildcard signature plus an invalid alternative signature: the invalid alternative alone does not prevent use of the independently validated source.
  • An independently authenticated source received with an expanded answer that lacks the required applicability proof: the source can be retained, but that answer cannot become Secure on that basis.
  • A cached source without the required authenticated association: it cannot be used for synthesis until the association is established.
  • A valid source with an expired signature, expired cache lifetime, incompatible denial proof, or proof crossing a delegation: the new containment check does not make synthesis permissible.
Conditional Label-Count Formulation This appendix is informative. M counts all non-root labels in S, including a leading wildcard label. Assume existing checks establish that O is within the authoritative signing zone S and that L is no greater than N. Then the requirements in are equivalent to this test: if L >= M: pass this containment test else if O == S and S has a leftmost wildcard label and L == M - 1: pass this containment test (exact apex only) else: fail this containment test Compare O and S using DNS case-insensitive equality. The exception requires exact owner/signer equality, not just an asterisk label. This test does not replace authority or signature-validation checks.
Acknowledgements The DNSSECVerif research was conducted by Qifan Zhang, Zilin Shen, Imtiaz Karim, Elisa Bertino, Daiping Liu, and Zhou Li. This document builds on that work and on the DNSSEC specifications cited above.