Signer-Zone Containment for DNSSEC Wildcard Validation

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 20 April 2027.¶

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

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 Section 3.1.3 of [RFC4034] and the reconstruction algorithm in Section 5.3.2 of [RFC4035] allow a validator to recover the owner name that was used to generate a signature. The checks in Section 5.3.1 of [RFC4035] 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 Section 5.3 of [RFC8198] can cross a zone boundary. The DNSSECVerif study identified this interaction [DNSSECVerif]. Public implementation reports are summarized in Section 3.1.¶

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 [RFC4592] 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 Section 5.2; Appendix B gives the conditional count-based formulation.¶

2. 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 [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:¶

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.¶

3. 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.¶

4. Updates to Validation and Wildcard Reuse

5. Compatibility and Deployment

6. 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.¶

7. IANA Considerations

This document has no IANA actions.¶

Appendix A. 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.¶

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.¶

Appendix B. 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 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.¶

Appendix C. 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.¶

Authors' Addresses