| Internet-Draft | ADEM over DNS | October 2026 |
| Linker | Expires 20 April 2027 | [Page] |
The ADEM Core Specification specifies the message format and authorization model for digital, distinctive emblems. This document specifies how such emblems can be used to mark domain names and how they can be conveyed over the DNS.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://adem-wg.github.io/adem-dns-spec/draft-linker-diem-adem-dns.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-linker-diem-adem-dns/.¶
Discussion of this document takes place on the Digital Emblems Working Group mailing list (mailto:diem@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/diem. Subscribe at https://www.ietf.org/mailman/listinfo/diem/.¶
Source for this draft and an issue tracker can be found at https://github.com/adem-wg/adem-dns-spec.¶
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 (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.¶
[I-D.linker-diem-adem-core] specifies the message format and authorization model of digital emblems recognized under International Humanitarian Law (IHL); in particular, it specifies the use of CBOR Web Tokens (CWTs) [RFC8392] and COSE_Key structures [RFC9052] for digital, distinctive emblems.
This draft specifies how such emblems can mark fully qualified domain names (FQDNs) using the DNS and the new IHLE DNS resource record (RR) type.¶
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 and message fields are used as defined in [RFC1035].¶
The IHLE (International Humanitarian Law Emblem) DNS RR type is used to mark an FQDN with a digital, distinctive emblem [I-D.linker-diem-adem-core].
The type value for the IHLE RR is TODO.¶
The RDATA for an IHLE RR consists of a single variable-length Token field.
The Token field MUST contain a CWT that either encodes an ADEM token or a COSE_Key structure containing ADEM-related public key material as specified in [I-D.linker-diem-adem-core].
The field consumes all octets indicated by RDLENGTH.
It MUST contain exactly one complete CBOR data item and MUST NOT contain trailing data.¶
When an IHLE RR contains an emblem, the emblem's assets claim MUST be an array (major type 4) of UTF-8 strings (major type 3).
Each string in this array MUST be an FQDN [RFC9499].
Relative names, i.e., without a terminating empty label, are permitted and MUST be interpreted relative to the empty root label.¶
The presentation format of the RDATA portion MUST represent the Token field as a sequence of case-insensitive hexadecimal digits. Whitespace is allowed within the hexadecimal text.¶
When a name server receives a query whose QNAME is the owner name of an IHLE RRset in the QCLASS, it MUST include that RRset in the Additional section of the response, unless the RRset is already included in the Answer section.
This requirement applies regardless of the query's QTYPE.¶
The server MUST NOT include only a subset of the IHLE RRset.
If the transport's size limit prevents the complete RRset from being included, the server MUST set the TC bit; the complete response returned following retry over a transport that permits a larger response MUST include the entire RRset.¶
ADEM tokens already are signed objects.
Thus, signing IHLE RRsets using DNSSEC is optional.
An IHLE RRset may be signed with DNSSEC, for example, because it is part of a signed zone.
Successful DNSSEC validation of the RRset, though, MUST NOT be treated as successful validation of any ADEM token it contains or as establishing trust in public key material for ADEM validation.¶
For distribution over the DNS, assets are identified by FQDNs.
To retrieve an asset's digital emblems, validators can perform a general DNS lookup, as specified in [RFC1034], with the asset's FQDN as QNAME, an arbitrary QTYPE, and the QCLASS IN.
When validators receive a set of tokens and public keys over the DNS, they validate it as follows:¶
Validate the set of tokens and public keys according to [I-D.linker-diem-adem-core].¶
If the validation procedure returns a result other than INVALID, verify that the queried FQDN occurs in the emblem's assets claim value using simple, case-insensitive string comparison.¶
A valid emblem that marks an FQDN signals that this domain name and services associated with this domain name are used for purposes protected under IHL. It signals that the domain name and services associated with that domain name should be respected, protected, and not disrupted. Intuitively speaking, the emblem has the function of a stop sign and signals that one should not use a domain name as part of an operation to disrupt services.¶
The emblem does not signal that systems which are identified by the domain name, e.g., via A or AAAA records, enjoy the same specific protections as the domain name itself.
For example, it could be that a domain name has an A record which contains an IP address that routes to a multi-tenant database server, and tenants are identified by the domain name.
That database server requires queries to include the domain of the tenant and, by itself, may not be protected.
Nevertheless, if one were to only discover this database server via a domain name that is marked with an emblem, there should be no reason to disrupt that database server.¶
TODO¶
TODO acknowledge.¶