JHU/APL

rahel.fainchtein@jhuapl.edu

Packet Clearing House

allison@pch.net

Architecture DNS DNSSEC DANE TODO Abstract About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

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 . 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 6 May 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 () 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

• .  Introduction
• .  Conventions and Definitions
• .  Assumptions
• .  DNS Structures of Digital Emblems
• .  Zone Cut Structure for Digital Emblems
• .  Digital Emblem Naming Structure
• .  Authentication and DNSSEC Architecture of DE's
• .  Emblems that are not Fully Contained in DNS
• .  Discovery
  • .  DNS Contained Emblem Discovery
  • .  External DE Discovery
• . Use of IANA Registries
• . Architecture for Authorizing Entities
  • .  Validation Procedure of ExtraZonal Authorization
  • .  Revoking Authorization
• . Security Considerations
• . IANA Considerations
• . References
  • .  Normative References
  • .  Informative References
• Acknowledgments
• Authors' Addresses

Introduction This document presents a DNS and DNSSEC forward architecture. That is, it assumes DNSSEC is required and defines an architecture in which different components or building blocks can be combined to achieve the needs of a particular use case, but where all of them are primarily realized using DNS and employ DNSSEC signing and validation. For each building block or set of blocks introduced we reference the set of requirements it meets and identify other blocks with which it would likely be used or implemented. This is intended to enable the construction of Digital Emblems that accommodate various granularity and temporality requirements. Note:Digital Emblem protocols that do not use/require DNSSEC signing and validation thereof should specify how they handle emblem validation (to the extent required for their intended use cases). Among the variations discussed in this document are cases where

• All of the DE's key information provided within DNS ();
• DE uses DNS pointers to resources outside of DNS that contain the emblem's key information ();
• DE primarily consists of a single RR ();
• DE consists of a bundle of separated RR's (RRSet) where each RR contains one or more pieces of the DE's core information ();

(Note:This list is not intended to be all inclusive.)

Conventions and Definitions 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.

Assumptions This document presents a DNS and DNSSEC forward architecture. That is, it assumes DNSSEC is required and defines an architecture in which different components are primarily realized using DNS and DNSSEC. * Cryptographic validation of Digital Emblems is required and is performed using DNSSEC. * Given the use of DNSSEC, all cases must meet the assured response requirement and a baseline version of consistent content outlined in Section 3.2.2. We discuss this in more detail and present a mechanism for supporting selective disclosure in .

DNS Structures of Digital Emblems Decisions have to be made when designing the protocol and applying it for a given use case. Generally speaking we recommend using a configuration that simplifies discovery and record maintenance but offer considerations for other approaches.

• Single RR w/everything vs multi RR/RRSet with each RR containing one or more pieces of core information
• Type(s) of RR(s) used within the Digital Emblem
  • TXT vs no TXT

Zone Cut Structure for Digital Emblems Since we assume the use of DNSSEC, or rather that all RRs/RRsets making up a digital emblem are DNSSEC signed, the authoritative server cannot deny the existence of any associated RRs/RRsets. As such, the only way to selectively disclose information within a digital emblem is for the authoritative server to hold two versions of any RRs that contain sensitive information or pointers thereto. Specifically:

• One that contains the sensitive information or pointers thereto (hidden RR). The hidden RR should only be presented if mutual authentication succeeds, and the requestor identity's membership in the set of authorized identities can be verified. Moreover, given the sensitivity of its contents, the hidden RR should be encrypted.
• One of the same type and for the same FQDN that only includes the basic and/or non-sensitive emblem information (default RR). This version of the RR should be returned by the Authoratative server if mutual authentication is not used, or if the requester's identity and/or authorization to see the sensitive content cannot be verified.

It is recommended that only RRtype(s) where the default RR does not indicate that sensitive details have been redacted or intentionally excluded from its contents be chosen.

Digital Emblem Naming Structure To ensure Digital Emblems and all of their associated records can be realized, underscored naming of attribute leaves should be used. Specifically, we propose the use of following underscored attribute names:

• _diem to denote a Digital Emblem.
• _authorizers as a subdomain of _diem (i.e. _authorizers._diem) to denote the set of authorizers for a Digital Emblem.
• etc As noted in , the standardization of these attributes and of their associated RRtypes will require registration in the appropriate IANA registry.

Authentication and DNSSEC Architecture of DE's TODO

Emblems that are not Fully Contained in DNS TODO

Discovery

DNS Contained Emblem Discovery

External DE Discovery

Use of IANA Registries If the use of underscored attribute leaves proposed in is to be adopted, all underscored names and their associated RRtypes will need to be added to the appropriate registry. (TODO: Update if consensus to use underscored naming is reached, remove otherwise.)

Architecture for Authorizing Entities Digital Emblems that require authorization from one or more entities outside of their zone should include an Authorizers field indicating the full list of entities that have authorized the issuance and use of a Digital Emblem. As illustrated in the figure above, each authorizer entry should contain the following fields.

• The Authorizer's common name (<AUTH_NAME>);
• The Authorizer's FQDN (<AUTH_FQDN>);And
• A collision resistant hash of all constraints the Authorizer has put on their authorization of the Digital Emblem, accompanied by a version number associated with the constraint set signed by the Authorizer (signed(HASH(constraints))).

To enable this the Authorizer publishes a DNSSEC signed authorization RR/RRset at the subdomain <DE_Name>.authorized.<AUTH_FQDN>. Within the RR/RRset they publish the version number of the current constraint set as well as the start and end date indicating the timeframe over which their authorization is valid. The authorizer then computes the hash of their constraints and signs over this, the constraint version number and the start and end dates of their authorization. To finalize the authorization, the authorizer sends the signed constraints hash and versioning metadata to the bearer, who then uses this to update the set of authorizers within the Digital Emblem. Note:To ease transitions from one set of constraints to another, or to handle reissuance of the authorization upon its expiration, Authorizers may host multiple authorization RRs/RRsets for the same emblem.

Validation Procedure of ExtraZonal Authorization To validate an emblem that is authorized by an external Authorizer, the validator must ensure that all of the following conditions hold:

1. DNSSEC validation of all RRs/RRsets within the Digital Emblem succeeds.
2. The emblem is authorized by an authorizer the validator trusts.
3. An Authorization RR/RRset exists at <DE_Name>.authorized.<TRUSTED_AUTH_FQDN>, where <TRUSTED_AUTH_FQDN> is the FQDN of the trusted Authorizer.
4. At least one authorization RR/RRset at <DE_Name>.authorized.<TRUSTED_AUTH_FQDN> can be validated. That is:
   • DNSSEC validation of the RR/RRset succeeds;
   • The version number noted in the Digital Emblem's authorizer record matches the constraint set version number;
   • The validity period of the authorization record has begun but not ended;
   • The Digital Emblem's use and/or claims comply with all of the constraints noted in the constraint set;And
   • The Hash of the constraint set and signature over it match those provided in the Digital Emblem's authorizer record.

If any of the conditions are not met, validation of the Digital Emblem has failed and the validator MUST reject it.

Revoking Authorization Based on the procedures described in and , an Authorizer can revoke their authorization of a Digital Emblem by removing the authorization RR(s)/RRset(s) located at <DE_Name>.authorized.<AUTH_FQDN>.

Security Considerations TODO Security

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] This document is a collection of technical clarifications to the DNS Security (DNSSEC) document set. It is meant to serve as a resource to implementors as well as a collection of DNSSEC errata that existed at the time of writing. This document updates the core DNSSEC documents (RFC 4033, RFC 4034, and RFC 4035) as well as the NSEC3 specification (RFC 5155). It also defines NSEC3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of the DNSSEC specification. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC. Informative References

Acknowledgments TODO acknowledge.

Authors' Addresses JHU/APL

rahel.fainchtein@jhuapl.edu

Packet Clearing House

allison@pch.net