| Internet-Draft | DNSSEC Wildcard Containment | October 2026 |
| Zhang, et al. | Expires 30 April 2027 | [Page] |
Validators for the DNS Security Extensions (DNSSEC) reconstruct the original owner name of a signed resource record set (RRset) using the RRSIG Labels field. This document updates RFC 4035 to make explicit how its existing signing-zone authority requirement applies to that reconstructed owner, and updates RFC 8198 to preserve the authenticated association between wildcard data, its original owner, and its signing zone during cache reuse. These clarifications prevent cryptographically correct signatures from being treated as authenticating wildcard sources outside the signing zone. They do not change DNS wildcard matching or synthesis rules, or DNS message formats.¶
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 30 April 2027.¶
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.¶
Section 5.3.1 of [RFC4035] requires the RRSIG Signer's Name to identify the zone containing the RRset as a condition for a resolver to authenticate that RRset. Section 3.1.7 of [RFC4034] states the same authority requirement. The RRSIG Labels field allows a validator to reconstruct the original signed owner name using the algorithm in Section 5.3.2 of [RFC4035]; Section 5.3.3 also requires verification that wildcard expansion was applied properly.¶
The reconstructed owner can differ from the received owner, but the reconstruction algorithm does not explicitly compare it with the Signer's Name. Checking only the received owner's relationship to the Signer's Name therefore does not fully enforce the existing authority requirement. This document makes the corresponding check on the reconstructed owner explicit; successful cryptographic verification cannot establish authority outside the signing zone.¶
The DNSSECVerif study identified implementation failures at this boundary [DNSSECVerif]; public reports are summarized in Section 3.1. Reuse under Section 5.3 of [RFC8198] can extend their effects. This document also specifies which authenticated information must remain associated when reusing wildcard data. Both clarifications apply to each candidate RRSIG and preserve the distinction between authenticating a wildcard source and proving its applicability to a query.¶
The scope is limited to reconstructed-owner containment and its preservation during wildcard reuse. The wildcard rules in [RFC4592], including expansion over multiple labels, remain unchanged, as do denial-of-existence algorithms, trust-anchor processing, and DNSSEC algorithm policy.¶
For a signing-zone apex whose leftmost label is not an asterisk, the explicit 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 Section 5.2; Appendix B gives the conditional count-based formulation.¶
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.¶
DNS terminology follows [RFC9499]. Wildcard domain name, closest encloser, and source of synthesis have the meanings in [RFC4592]. This document uses the following notation for one candidate RRSIG and the RRset it covers:¶
Name equality and subdomain comparisons use complete DNS labels and the case-insensitive rules in [RFC4343]. 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.¶
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. Treating that signature as authenticating the reconstructed owner would violate the existing signing-zone authority requirement.¶
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 containment 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.¶
Public vendor reports document practical consequences of insufficient RRSIG Labels validation in deployed resolver software:¶
The reported prerequisites and consequences differ across implementations. These reports motivate making the authority and cache-association checks explicit; they do not establish identical defects or conformance of the published fixes to all requirements in this document.¶
To make the authority requirement in Section 5.3.1 of [RFC4035] explicit during owner reconstruction, add the following sentence to Section 5.3.2, immediately after the algorithm that calculates the owner name used in the signed data:¶
A validator MUST NOT use a candidate RRSIG to authenticate an RRset or a reconstructed wildcard source unless the reconstructed original owner is a strict subdomain of the Signer's Name or is equal to both the Signer's Name and the received RRset owner, with all comparisons performed on complete DNS labels under the case-insensitive rules of [RFC4343].¶
Existing key-authentication and zone-authority checks, including zone-cut rules and parent-side DS handling, continue to apply; name containment does not replace them. The containment check can precede cryptographic verification, whose success cannot override a failed check.¶
A failure rejects that candidate RRSIG, not other signatures covering the RRset. Alternative signatures and the final validation result remain governed by Section 5.4 of [RFC6840].¶
Equality permits exact-apex RRsets, including an asterisk-named apex. When R differs from O, R must lie strictly below S, excluding that apex as a source of synthesis; see Section 5.2.¶
Append the following text to Section 5.3 of [RFC8198]:¶
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, [RFC5155], and their applicable updates. Existing TTL and signature-validity limits, including the changes in [RFC9077], are unchanged.¶
Under Section 3.3.1 of [RFC4592], 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 explicit 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 Section 3 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.¶
Section 4.1 of [RFC4592] 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 explicit 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 containment check.¶
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. Appendix B gives a conditional count-based formulation.¶
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 containment check with R = O = child.example.; it is then evaluated using the existing parent-side DS rules.¶
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.¶
This document has no IANA actions.¶
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.¶
| O | S | L | R | Result |
|---|---|---|---|---|
| a.c.example. | c.example. | 3 | a.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. | 2 | child.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:¶
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 Section 4.1 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.¶
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.¶