DNS-Anchored Durable Identity for AI Agents (DNSid)
draft-ihsanullah-dnsid-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Naveed Ihsanullah | ||
| Last updated | 2026-06-28 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ihsanullah-dnsid-01
Individual Submission N. Ihsanullah
Internet-Draft Identity Digital
Intended status: Standards Track 29 June 2026
Expires: 31 December 2026
DNS-Anchored Durable Identity for AI Agents (DNSid)
draft-ihsanullah-dnsid-01
Abstract
Autonomous software agents are being deployed across enterprise,
cloud, and cross-organizational boundaries. These agents negotiate,
transact, delegate, and produce work products that persist beyond
their own ephemeral runtime. Current standards and initiatives for
agent identity collectively address runtime authentication,
authorization, lifecycle management, and tool interaction, but a gap
remains: a durable, governance-backed identifier that lets a relying
party determine and verify the accountable entity behind an agent it
encounters, including agents that have since been retired or whose
keys have rotated, and attribute past and present work products to
that entity. Lifecycle-history verification is governed by the
applicable log method and deployment scope.
DNSid addresses the accountable layer of identity: the durable
ownership anchor that existing agent identity standards do not
provide. This document specifies DNSid, a minimal identity primitive
that assigns each agent a Fully Qualified Domain Name (FQDN), binds
it to an accountable entity identified by a DNS domain under that
entity's control, and publishes a structured set of pointers in DNS
TXT records to the agent's cryptographic keys, lifecycle log, and
operational status. DNSid uses accountable-entity-controlled
signatures for record integrity and an abstract append-only lifecycle
log for history. It is designed to sit beneath existing identity,
authentication, authorization, and agent interaction standards
without competing with them.
DNSid introduces no new DNS resource record types, opcodes, or
response codes, and requires no changes to DNS resolvers,
authoritative servers, or the DNS protocol. It applies to any agent
that can be assigned an FQDN whose accountable entity can publish
verification material; public discoverability of the agent is not
required.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Ihsanullah Expires 31 December 2026 [Page 1]
Internet-Draft DNSid June 2026
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 31 December 2026.
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 and Motivation . . . . . . . . . . . . . . . . . 4
1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Why DNS . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Design Principles . . . . . . . . . . . . . . . . . . . . 5
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 7
3. Ecosystem Context and Scope . . . . . . . . . . . . . . . . . 9
3.1. What DNSid Addresses (Layer 1) . . . . . . . . . . . . . 9
3.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Trust Architecture . . . . . . . . . . . . . . . . . . . . . 10
4.1. Governance Anchor: Registrant Domain . . . . . . . . . . 11
4.2. Technical Identity Anchor: Agent FQDN . . . . . . . . . . 12
4.3. Integrity and History Anchor: Lifecycle Log . . . . . . . 12
5. The DNSid TXT Record . . . . . . . . . . . . . . . . . . . . 13
5.1. Owner Name Convention . . . . . . . . . . . . . . . . . . 13
5.2. Record Format . . . . . . . . . . . . . . . . . . . . . . 14
5.3. Tag Definitions . . . . . . . . . . . . . . . . . . . . . 15
5.4. GI (Governance Identifier) Tag . . . . . . . . . . . . . 16
5.5. LR (Log Reference) Tag . . . . . . . . . . . . . . . . . 17
5.6. FL (Policy Flags) Tag . . . . . . . . . . . . . . . . . . 17
5.7. KA (Key Age Maximum) Tag . . . . . . . . . . . . . . . . 18
Ihsanullah Expires 31 December 2026 [Page 2]
Internet-Draft DNSid June 2026
5.8. Multi-String Encoding . . . . . . . . . . . . . . . . . . 19
6. Entity-Signed Record Integrity . . . . . . . . . . . . . . . 19
6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Signature Generation . . . . . . . . . . . . . . . . . . 20
6.3. Signature Verification . . . . . . . . . . . . . . . . . 21
6.4. Relationship to DNSSEC . . . . . . . . . . . . . . . . . 21
7. HTTP Service Interfaces . . . . . . . . . . . . . . . . . . . 23
7.1. Operational Key Service (KU endpoint) . . . . . . . . . . 23
7.2. Entity Key Service (EK endpoint) . . . . . . . . . . . . 24
7.3. Status Service (SU endpoint) . . . . . . . . . . . . . . 25
7.4. Private and Access-Controlled Deployments . . . . . . . . 26
8. Abstract Log Interface . . . . . . . . . . . . . . . . . . . 27
8.1. Log Identification . . . . . . . . . . . . . . . . . . . 27
8.2. Required Properties . . . . . . . . . . . . . . . . . . . 27
8.3. Entry Signing . . . . . . . . . . . . . . . . . . . . . . 28
8.4. Event Types . . . . . . . . . . . . . . . . . . . . . . . 29
9. Verification Protocol . . . . . . . . . . . . . . . . . . . . 31
9.1. Interactive Verification . . . . . . . . . . . . . . . . 31
9.2. Historical Verification . . . . . . . . . . . . . . . . . 33
10. Lifecycle Events . . . . . . . . . . . . . . . . . . . . . . 33
10.1. Agent States . . . . . . . . . . . . . . . . . . . . . . 33
10.2. Identity Lifecycle Flexibility . . . . . . . . . . . . . 34
10.3. Key Rotation Procedure . . . . . . . . . . . . . . . . . 35
10.4. Status Change Propagation . . . . . . . . . . . . . . . 36
11. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 37
12. Security Considerations . . . . . . . . . . . . . . . . . . . 37
12.1. Entity Signature and DNSSEC . . . . . . . . . . . . . . 37
12.2. Two-Key Separation . . . . . . . . . . . . . . . . . . . 38
12.3. TXT Record Ambiguity . . . . . . . . . . . . . . . . . . 39
12.4. TTL and Caching . . . . . . . . . . . . . . . . . . . . 39
12.5. Record Absence and Negative Caching . . . . . . . . . . 39
12.6. Post-Quantum Considerations . . . . . . . . . . . . . . 39
12.7. Log Durability . . . . . . . . . . . . . . . . . . . . . 40
12.8. Revocation and Accountability . . . . . . . . . . . . . 41
12.9. URI Integrity . . . . . . . . . . . . . . . . . . . . . 42
12.10. Future Profile Considerations . . . . . . . . . . . . . 42
13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 43
13.1. Encrypted DNS Transport . . . . . . . . . . . . . . . . 43
13.2. TLS Handshake Privacy . . . . . . . . . . . . . . . . . 43
13.3. Privacy and Pseudonymity . . . . . . . . . . . . . . . . 43
13.4. Log Privacy . . . . . . . . . . . . . . . . . . . . . . 44
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
14.1. DNSid TXT Tag Names Registry . . . . . . . . . . . . . . 44
14.2. DNSid Policy Flag Names Registry . . . . . . . . . . . . 45
14.3. DNSid Log Method Registry . . . . . . . . . . . . . . . 46
14.4. DNSid Underscore Label Registration . . . . . . . . . . 46
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
15.1. Normative References . . . . . . . . . . . . . . . . . . 46
Ihsanullah Expires 31 December 2026 [Page 3]
Internet-Draft DNSid June 2026
15.2. Informative References . . . . . . . . . . . . . . . . . 48
Appendix A. Relationship to Adjacent Standards . . . . . . . . . 51
Appendix B. Ecosystem Relationship Map . . . . . . . . . . . . . 53
Appendix C. Migration Path to Dedicated RR Type . . . . . . . . 55
Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 55
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction and Motivation
1.1. The Problem
AI agents are moving from prototypes into production. They operate
autonomously, acquire tools dynamically, delegate to other agents,
and produce work products (reports, code, transactions, decisions)
that persist and can cross organizational boundaries even after the
agent terminates. Existing identity and access management systems
can authenticate workloads and authorize actions within a platform,
but they cannot answer a more fundamental question:
Which accountable entity is responsible for this agent, and can
any system verify that independently, without depending on a
centralized registry it must trust to be honest and available?
Existing standards and initiatives for agent identity and
authorization, including OAuth 2.1 [OAuth2.1], OIDC [OIDC], SPIFFE/
SPIRE [SPIFFE], SCIM [SCIM], NGAC [NGAC], and MCP [MCP], collectively
address runtime authentication, authorization, lifecycle management,
and tool interaction. None of these, by itself, provides a durable,
governance-backed ownership anchor that persists across platforms,
trust domains, and agent lifecycles.
Nor do they answer the temporal form of the question: which
accountable entity owned this agent at a specific past time?
Mechanisms that rely on current control, such as TLS certificates,
workload credentials, or live DNS records, provide no answer once the
domain is transferred, the credential expires, or the agent is
decommissioned. Post-incident forensics, regulatory audits, and
cross-organizational accountability depend on a record of ownership
that persists after the agent itself is gone.
Ihsanullah Expires 31 December 2026 [Page 4]
Internet-Draft DNSid June 2026
For example, an agent may sign a financial report, delegate work to
other agents, and then terminate. Months later, an auditor or
counterparty may need to determine which accountable entity was
responsible, which key was active at the time, and whether the agent
had been revoked or retired. Without a durable, independently
verifiable ownership anchor, that determination depends on the
platform or credential system that happened to run the agent at the
time, and the accountability chain can be lost when systems,
credentials, or providers change.
1.2. Why DNS
DNS is the most widely deployed globally delegated namespace with:
* Universal resolvers: DNS resolution is available to virtually all
internet-connected systems.
* Governance-backed domain accountability: domain registration
relationships, namespace governance processes, and dispute
resolution mechanisms already provide an operational framework for
managing control of DNS names.
* Existing operational use in organizational trust: TLS, email
authentication (SPF, DKIM, DMARC), and PKI already depend on DNS
for organizational binding.
* 40+ years of deployment with no migration required.
Keeping agent identifiers in the DNS namespace allows relying parties
to reuse the same operational, governance, and security plane already
used for web, email, and commerce infrastructure, and avoids
introducing a separate namespace whose binding to existing internet
identities would require its own trust model. Building a new
identity protocol from scratch would create a parallel naming system
and a new trust root, and would require its own standardization and
deployment path. DNSid extends DNS from resolving domain names to
anchoring agent identifiers, building on infrastructure that is
already widely deployed, protocol-neutral, and institutionally
governed.
1.3. Design Principles
DNSid is intentionally minimal:
* Smallest viable surface area. DNSid does one thing: bind an agent
identity and its operational key to an accountable entity via DNS,
with pointers to keys, status, and history. It supports
verification of the agent's DNSid identity but does not define a
Ihsanullah Expires 31 December 2026 [Page 5]
Internet-Draft DNSid June 2026
general application-layer authentication, authorization, IAM,
policy-enforcement, behavior-monitoring, or runtime execution
stack.
* Pointer set, not data store. The DNS record carries structured
pointers to HTTPS endpoints and log entries. Rich identity data,
claims, and attestations live at those endpoints, not in DNS. DNS
serves as the authoritative rendezvous layer for identity
resolution. This applies to agent ownership the same pattern that
DKIM [RFC6376] and DMARC [RFC9989] applied to email
authentication: a small, well-scoped record at a reserved
underscore label publishes cryptographic material and pointers,
while the substantive data is served elsewhere. Publishing key
references rather than inline keys is also deliberate for crypto
agility; see Section 12.6.
* Accountable-entity-controlled record integrity. Record integrity
is established by the accountable entity's own cryptographic key,
not by the DNS hierarchy's signing chain. DNSSEC, when present,
authenticates DNS-origin integrity for the owner name and is
complementary to the entity signature. Deployment profiles
requiring DNS-origin authentication independent of WebPKI require
DNSSEC (see Section 6.4).
* Log-technology-neutral. The specification defines what lifecycle
events must be recorded and what proof properties the log must
provide. It does not mandate a specific log technology or require
public accessibility.
* Standards-complementary. DNSid sits beneath SPIFFE, OAuth, OIDC,
SCIM, NGAC, MCP, A2A [A2A], DIDs, VCs, and AGENTS.md [AGENTS.md].
It is intended to provide a governance-backed anchor those
mechanisms can reference but do not themselves define.
* Pseudonymity with pierceability. Each DNSid FQDN is a
disconnected pseudonymous handle. The agent operates under its
FQDN without exposing the accountable entity to casual observers.
Resolving the accountable entity may require registrar, registry,
or legal process. Use of distinct registrable domains provides
operational separation of pseudonymous identities. This is a
deliberate privacy-by-design property of anchoring identity in the
registrant-domain governance layer.
* Accountability terminates at a registrant. The entity named by
"gi" is the registrant of its own ("gi") domain: a real-world
organization or person reachable through registration governance,
not another agent. Accountability rests on this "gi" registrant;
the agent's own FQDN carries no accountability weight of its own
Ihsanullah Expires 31 December 2026 [Page 6]
Internet-Draft DNSid June 2026
and may be an inexpensive or opaque name. The accountability
chain therefore terminates at the "gi" registrant rather than in
agent-to-agent recursion.
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.
Agent FQDN: The Fully Qualified Domain Name assigned to an agent.
This is the agent's primary globally unique identifier. Examples
include billing-agent-acme.example for a dedicated registrable-
domain deployment, billing-agent.acme-corp.example for a shared
organizational-domain deployment, and agent-7f3a9c2b.example where
the agent name is an opaque, algorithmically generated identifier.
Governance Anchor: The registrant domain under which the agent FQDN
is published, typically a registrable domain. The registrant of
this domain is the accountable entity for all agents beneath it.
When the agent is registered as a dedicated registrable domain,
the FQDN and governance anchor are the same (e.g., billing-agent-
acme.example serves as both). Under a shared domain, the
governance anchor is the organizational domain (e.g., acme-
corp.example).
DNSid TXT Record: A DNS TXT Resource Record (TXT RR) published at
the owner name _dnsid.<agent-fqdn> containing a structured set of
key-value tags that encode DNSid identity pointers.
Verifier: An agent, service, or relying party that resolves and
validates a DNSid TXT record.
Lifecycle Log: An append-only verifiable data structure, such as a
transparency log, Merkle tree, blockchain application, or SCITT-
compatible service, that records DNSid lifecycle events with
cryptographic inclusion proofs and verifiable timestamps.
Durable Public-Key Reference: A reference to public key material
Ihsanullah Expires 31 December 2026 [Page 7]
Internet-Draft DNSid June 2026
that remains resolvable for as long as historical verification is
required, such that the key material can be recovered to verify a
past signature. A bare hash or thumbprint is not a durable
public-key reference, because it does not yield the key material
needed for signature verification. Examples include key material
recorded inline in a lifecycle-log event, or a content-addressed
or transparency-log-anchored reference that the applicable log
method guarantees to remain retrievable.
Accountable Entity: The party that registered the agent, bears
responsibility for its behavior, and holds authority to revoke it.
The accountable entity may be an organization or an individual.
This is distinct from intellectual property ownership or runtime
control.
Verification Scope: The set of verifiers, deployment contexts, or
access conditions under which a log binding makes lifecycle
entries or portable cryptographic proofs available. The
verification scope is determined by the log binding specification
and the accountable entity's deployment choice.
Accountable Entity Record-Signing Key: The cryptographic key pair
controlled by the accountable entity, used to sign the DNSid TXT
record ("sg" tag) and to sign lifecycle events recorded by this
DNSid. Public half published via the JWKS endpoint discovered by
the "ek" tag. Distinct from any key issued by a certificate
authority or DNS operator.
DNSid Operational Key: The cryptographic key pair used by the DNSid
(the agent) for runtime operations: challenge-response during
verification, agent message signing and profile-defined work-
product signing, and the DNSid's countersignature on the ISSUANCE
lifecycle event. Public half published via the JWKS endpoint
discovered by the "ku" tag. Distinct from the accountable entity
record-signing key.
Self-Accounted DNSid: A deployment in which the DNSid subject is its
own accountable entity, where "gi" names the agent's own domain
(the agent FQDN, or a parent domain of it). Self-accounting is
determined by this name relationship between the agent FQDN and
"gi", not by reuse of key material: a single operator may control
both roles, but the accountable entity record-signing key ("ek")
and the DNSid operational key ("ku") remain distinct (see
Section 12.2). Classifying a DNSid as self-accounted does not by
itself complete verification; when a verifier relies on the
operational DNSid identity, the status and ISSUANCE/key-continuity
checks in Section 9 still apply, while record-integrity-only and
offline historical processing follow their own requirements.
Ihsanullah Expires 31 December 2026 [Page 8]
Internet-Draft DNSid June 2026
Delegated DNSid: A deployment in which the DNSid subject operates
under a distinct accountable entity (the entity named by "gi" is
different from the agent FQDN's organization).
3. Ecosystem Context and Scope
3.1. What DNSid Addresses (Layer 1)
The agent identity ecosystem organizes into a layered model. DNSid
occupies Layer 1, the durable accountable ownership anchor: the
governance-backed binding of an agent to the entity accountable for
it, which persists across platforms, trust domains, and agent
lifecycles.
+=======+=============================+==========================+
| Layer | Name | Representative Standards |
+=======+=============================+==========================+
| 0 | Global Namespace Governance | ICANN, DNSSEC, DANE |
+-------+-----------------------------+--------------------------+
| 1 | Durable Accountable | *DNSid operates here* |
| | Ownership Anchor | |
+-------+-----------------------------+--------------------------+
| 2 | Cryptographic Identity | DIDs, VCs, PKI |
| | Binding | |
+-------+-----------------------------+--------------------------+
| 3 | Runtime Workload Identity | SPIFFE/SPIRE |
+-------+-----------------------------+--------------------------+
| 4 | Authentication | OAuth 2.1, OIDC, RFC |
| | | 9421 |
+-------+-----------------------------+--------------------------+
| 5 | Authorization and Policy | NGAC, OPA, Cedar |
+-------+-----------------------------+--------------------------+
| 6 | Operational Governance | NHI platforms, SCIM |
+-------+-----------------------------+--------------------------+
| 7 | Discovery and | MCP, A2A, AGNTCY |
| | Interoperability | [AGNTCY] |
+-------+-----------------------------+--------------------------+
Table 1
Existing standards and initiatives concentrate at Layers 2 through 7.
Layer 1 (a durable, independently verifiable record of which
accountable entity owns an agent over time) is sparsely populated.
DNSid addresses this layer specifically and does not duplicate the
others.
Ihsanullah Expires 31 December 2026 [Page 9]
Internet-Draft DNSid June 2026
3.2. Non-Goals
The scope boundaries below are explicit design decisions, not gaps.
This specification explicitly does not:
* Define a general runtime authentication protocol, session model,
IAM provider, or SSO mechanism (Layer 4).
* Attest workloads within a trust domain (Layer 3: SPIFFE).
* Issue or manage verifiable credentials (Layer 2: DIDs, VCs).
* Enforce authorization policies (Layer 5: NGAC, OPA).
* Monitor agent behavior (Layer 6: NHI platforms).
* Provide agent discovery or agent-to-agent communication protocols
(Layer 7: MCP, A2A).
* Replace endpoint control or firewall functionality.
* Define a new cryptographic primitive, a global trust framework, or
a compliance regime.
* Determine whether an accountable entity is trustworthy, reputable,
or legally qualified. Such determinations are made by consuming
systems, external registries, Verifiable Credentials, or local
policy.
Participation is voluntary: an accountable entity may decline to
publish DNSid records, and a relying party may decline to require
them. Though recommended, DNSSEC is not required for the base
profile (see Section 6.4). The systems above are consumers of the
ownership anchor DNSid provides; they reference the DNSid identity to
make their own trust, authorization, and enforcement decisions.
4. Trust Architecture
DNSid separates three distinct anchors of trust. Each anchor
addresses a different verification need.
DNSid verification addresses three distinct claims. Separating them
clarifies the role of each mechanism:
Ihsanullah Expires 31 December 2026 [Page 10]
Internet-Draft DNSid June 2026
+==============+=====================+==========================+
| Claim | Question | DNSid Mechanism |
+==============+=====================+==========================+
| Record | Was this TXT record | Entity signature ("sg" |
| integrity | signed by the | tag) verified against |
| | accountable entity? | JWKS over HTTPS |
+--------------+---------------------+--------------------------+
| DNS | Was the DNS | DNSSEC, when deployed; |
| authenticity | response tampered | absent = reduced |
| | with in transit? | assurance |
+--------------+---------------------+--------------------------+
| Real-world | Is the accountable | Out of scope; determined |
| legitimacy | entity trustworthy | by relying-party policy, |
| | or reputable? | external registries, or |
| | | Verifiable Credentials |
+--------------+---------------------+--------------------------+
Table 2
The entity signature and DNSSEC are independent integrity properties
operating on different channels (HTTPS and DNS respectively). The
third claim is explicitly outside DNSid's scope.
The binding between an agent and its accountable entity is mutual
rather than imposed. The ISSUANCE event is signed by the
accountable-entity record-signing key ("ek") and countersigned by the
agent's operational key ("ku"), so an accountable entity cannot
unilaterally claim an agent without that agent's consent.
Operational control of the identity remains with "ku": operational-
key rotation is authorized by the previous "ku", not by "ek". The
accountable entity's role is accountability, including revocation,
not impersonation.
4.1. Governance Anchor: Registrant Domain
The registrant domain is the governance root. The registrant is
subject to domain registration agreements, namespace governance
policy, and established dispute resolution processes. This
governance is not something DNSid creates; it already exists for
every domain registrant on the internet. DNSid is designed to
operate within existing DNS infrastructure and should not require new
governance processes, TLD allocations, or registrar categories.
The governance and pseudonymity properties are strongest when each
agent is registered as a dedicated registrable domain (e.g., billing-
agent-acme.example). Each registrable domain constitutes a distinct
registrant relationship, a distinct accountability scope, and a
distinct operational zone with independent DNSSEC signing and
Ihsanullah Expires 31 December 2026 [Page 11]
Internet-Draft DNSid June 2026
administrative control. Organizations MAY anchor agents under an
existing organizational domain (e.g., billing-agent.acme-
corp.example), accepting that agents under a shared domain share
governance, accountability, and pseudonymity scope.
Agent FQDNs are not required to carry human-readable names. The
Agent FQDN need not host a human-facing website or reveal the agent's
purpose. Organizations seeking maximum pseudonymity MAY register
opaque identifiers as agent FQDNs, since the agent's purpose and
capabilities are described in the capabilities document referenced by
the "cu" tag, not in the domain name itself.
When a platform hosts agents on behalf of users, the platform
registrant is the accountable entity under DNSid. Attribution of
responsibility to individual users is handled through the platform's
internal audit trail and administrative processes, not through DNSid
itself.
4.2. Technical Identity Anchor: Agent FQDN
Each agent is assigned a globally unique FQDN as its governance
anchor (e.g., billing-agent-acme.example). When registered as a
dedicated registrable domain, the FQDN is itself the governance
anchor. When registered under an organizational domain (e.g.,
billing-agent.acme-corp.example), the FQDN inherits the governance
posture of the parent registrant domain. In either case, the FQDN is
the identifier that other agents, registries, and relying services
carry in protocol messages.
The agent's public signing keys are published at an HTTPS endpoint
(JWKS format) referenced by the DNSid TXT record. The key service
MUST support algorithm negotiation to enable crypto agility for the
transition to post-quantum signature algorithms (NIST FIPS 204 ML-
DSA, FIPS 205 SLH-DSA) [NIST-PQC].
4.3. Integrity and History Anchor: Lifecycle Log
DNS is a current-state naming system. It does not provide durable
evidence of prior key bindings, revocation events, retirement, or
identity migration after DNS records change or a domain is
transferred. The HTTPS endpoints referenced by the TXT record are
controlled by whoever controls the domain now, not necessarily
whoever controlled it when an artifact was signed, an incident
occurred, or a key was rotated. The lifecycle log supplies this
missing temporal property: it records signed lifecycle events so that
verifiers can evaluate agent identity and key validity at a point in
time, not merely at the moment of DNS resolution.
Ihsanullah Expires 31 December 2026 [Page 12]
Internet-Draft DNSid June 2026
An append-only verifiable log records the core agent identity
lifecycle: issuance, key rotation, revocation, retirement, and
migration. Optional event types can extend coverage to delegation
and other profile-defined events. The lifecycle log is initially
bound to the agent FQDN through the ISSUANCE event, which is signed
by the accountable entity and countersigned by the initial
operational key.
DNS publishes the current owner-name binding for the FQDN; DNSSEC,
WebPKI endpoint checks, and lifecycle-log evidence determine the
assurance with which that binding is accepted. The lifecycle log
records what has happened under that identity over time. Together
they provide a temporal picture that neither provides alone.
Lifecycle log entries are signed by the authorizing key specified for
each event type. For all events except KEY_ROTATION, that
authorizing key is the accountable entity's record-signing key;
KEY_ROTATION is authorized by the previous operational key (see
Section 8.3). The log itself may be operated by any party; what
matters is that entries carry the required event-specific authorizing
signature(s) and cannot be forged by the log operator. The
lifecycle-log model supports optional and profile-defined extensions,
such as delegation records or artifact-provenance receipts, alongside
the core identity lifecycle events.
The lifecycle log may be instantiated as a blockchain, Merkle tree,
Certificate Transparency [RFC6962] style log, or similar verifiable
data structure. The architectural requirement is append-only
integrity with cryptographic inclusion proofs, not a specific
implementation. See Section 8 for the abstract log interface.
5. The DNSid TXT Record
5.1. Owner Name Convention
A DNSid TXT record MUST be published at the owner name (the DNS term
for the left-hand side of a resource record) formed by prepending the
label "_dnsid" to the agent FQDN:
_dnsid.<agent-fqdn>
Example:
_dnsid.billing-agent-acme.example.
Ihsanullah Expires 31 December 2026 [Page 13]
Internet-Draft DNSid June 2026
The underscore prefix follows the underscore scoping model of
[RFC8552] and the convention established by DKIM (_domainkey), DMARC
(_dmarc), and MTA-STS (_mta-sts), creating a dedicated namespace that
does not collide with TXT records used by other protocols at the
agent FQDN itself.
The TXT RRset at the _dnsid owner name MUST contain exactly one TXT
RR, and that TXT RR MUST contain exactly one DNSid record beginning
with "v=DNSid1". If the RRset contains zero TXT RRs, more than one
TXT RR, or a TXT RR that cannot be parsed as a single DNSid record,
verification MUST fail.
The agent FQDN MUST NOT exceed 246 octets in presentation format,
ensuring the derived owner name _dnsid.<agent-fqdn> does not exceed
the 253-octet presentation limit ([RFC1035] Section 2.3.4, [RFC1123]
Section 2.1).
The TTL of DNSid TXT records SHOULD be kept short enough to support
timely revocation propagation.
5.2. Record Format
The RDATA of the DNSid TXT record is a sequence of tag=value pairs
separated by semicolons, following the tag=value conventions of
Section 3.2 of [RFC6376] (DKIM Signatures), with the stricter grammar
defined below. The record MUST begin with the version tag
"v=DNSid1". Placing the version tag first allows a parser to quickly
determine whether the TXT record is a DNSid record before parsing the
remaining tags, following the convention established by DKIM
([RFC6376]) and DMARC ([RFC9989]). The version string includes the
protocol identifier to distinguish DNSid records from other TXT
records that may exist at the same owner name.
The record carries references to key services ("ek", "ku") rather
than inline public keys, deliberately, so the DNS wire format is not
coupled to algorithm-specific key sizes; see Section 12.6.
Formal syntax (ABNF, [RFC5234]):
dnsid-record = dnsid-v-tag *( ";" SP? dnsid-tag ) [ ";" ]
dnsid-v-tag = %s"v" "=" %s"DNSid1"
dnsid-tag = dnsid-tag-name "=" dnsid-tag-value
dnsid-tag-name = ALPHA *( ALPHA / DIGIT / "_" )
dnsid-tag-value = *( %x21-3A / %x3C-7E )
; printable ASCII excluding ";" and space
Tag names are case-sensitive. Unknown tags MUST be ignored by
receivers to provide forward-compatibility for future extensions.
Ihsanullah Expires 31 December 2026 [Page 14]
Internet-Draft DNSid June 2026
A DNSid TXT record MUST NOT contain duplicate tag names. A verifier
MUST reject a record containing duplicate tag names.
Unknown tags are ignored for semantic processing but are included in
the canonical record string for signature verification.
These rules make DNSid1 extensible within its version: future
specifications can define additional OPTIONAL tags, registered
through the DNSid TXT Tag Names Registry under its Specification
Required policy (Section 14). Existing receivers ignore such tags
semantically, but the tag data remains included in the canonical
record string used for signature verification, so extension data is
integrity-protected even when a verifier does not understand it.
Changing the version tag itself, for example a future "v=DNSid2", is
a version transition rather than an extension. A record under a
different version is not a usable DNSid1 record and is not accepted
for DNSid1 verification, consistent with the "v=DNSid1" requirement
above and the singleton rule in Section 5.1. DNSid1 therefore
defines no overlapping-version behavior; Appendix C discusses what a
future transition, including migration to a dedicated RR type, would
need to specify.
5.3. Tag Definitions
+=====+==========+===============================================+
| Tag | Required | Description |
+=====+==========+===============================================+
| v | REQUIRED | Version. MUST be "DNSid1". MUST be first |
| | | tag. |
+-----+----------+-----------------------------------------------+
| gi | REQUIRED | Governance identifier. Links the agent FQDN |
| | | to its governance anchor (the accountable |
| | | entity). |
+-----+----------+-----------------------------------------------+
| ek | REQUIRED | Entity key URI. HTTPS URL for the |
| | | accountable entity's record-signing keys in |
| | | JWKS format ([RFC7517]). The key discovered |
| | | via "ek" signs the "sg" tag. |
+-----+----------+-----------------------------------------------+
| ku | REQUIRED | Key URI. HTTPS URL for the DNSid's |
| | | operational (runtime) signing keys in JWKS |
| | | format ([RFC7517]). |
+-----+----------+-----------------------------------------------+
| lr | REQUIRED | Log reference. Structured reference |
| | | identifying the log binding and the agent's |
| | | entry. |
+-----+----------+-----------------------------------------------+
Ihsanullah Expires 31 December 2026 [Page 15]
Internet-Draft DNSid June 2026
| su | REQUIRED | Status URI. HTTPS URL for registration and |
| | | revocation status. |
+-----+----------+-----------------------------------------------+
| sg | REQUIRED | Entity signature. Base64url-encoded |
| | | signature by the accountable entity's record- |
| | | signing key (the key discovered via "ek"), |
| | | computed over the canonical record content. |
+-----+----------+-----------------------------------------------+
| fl | OPTIONAL | Policy flags. Comma-separated list of named |
| | | flags. |
+-----+----------+-----------------------------------------------+
| ka | OPTIONAL | Maximum signing key age. Duration value. |
| | | Applies to the DNSid operational key at "ku". |
+-----+----------+-----------------------------------------------+
| cu | OPTIONAL | Capabilities URI. HTTPS URL for an AGENTS.md |
| | | or Agent Card document. |
+-----+----------+-----------------------------------------------+
Table 3
Implementations MUST reject a DNSid TXT record that is missing any
REQUIRED tag or in which a REQUIRED tag has an empty value.
5.4. GI (Governance Identifier) Tag
The "gi" tag identifies the accountable entity controlling this
agent. In this specification the "gi" value MUST be a domain name
(the registrant domain) in lowercase ASCII; internationalized domain
names use their lowercase A-label form ([RFC5890]). Non-domain
identifiers for the accountable entity (for example, a URI into an
external registry, a Decentralized Identifier, or a Verifiable
Credential subject) are reserved for future profiles and MUST NOT be
used in the base profile.
Examples:
gi=billing-agent-acme.example
gi=acme-corp.example
The "gi" value MUST be consistent with the domain hierarchy under
which the agent FQDN is published, satisfied by either:
* the agent FQDN is a subdomain of (or equal to) the domain
identified by "gi" (the self-accounted and subdomain-delegated
cases); or
Ihsanullah Expires 31 December 2026 [Page 16]
Internet-Draft DNSid June 2026
* for a delegated DNSid whose agent FQDN is not under the "gi"
domain, the bilateral ISSUANCE event (see Section 9.1 and
Section 8.4) records the "gi" value and binds it to the agent.
The ISSUANCE evidence is the base mechanism that satisfies this
governance-relationship condition; no separate registry lookup is
defined.
If neither condition holds, the verifier MUST reject the record.
The "gi" tag identifies the accountable entity; the "ek" tag
(Section 5.3) discovers that entity's record-signing key. Because
"gi" is a domain name, the "ek" URI host MUST be the domain
identified by "gi" or a host under that domain. This document does
not define a fallback by which "ek" is derived from "gi".
5.5. LR (Log Reference) Tag
The "lr" tag is a DNSid log reference identifying the log technology
and the agent's primary entry. The method component of the reference
identifies the log binding; the remaining components locate the
agent's log entry.
This specification does not mandate a specific log method.
Implementations SHOULD register their method name with the DNSid Log
Method Registry (Section 14).
Examples (method names are illustrative):
lr=algorand:AGENT_ADDR_BASE32
lr=ctlog:https://log.example.com/agents/entries/12345
lr=scitt:https://transparency-service.example/entry/abc123
5.6. FL (Policy Flags) Tag
The "fl" tag is a comma-separated list of named policy flags.
Unknown flag names MUST be ignored by receivers.
Policy flags are meaningful only to verifiers that understand the
named flag; they are not an access-control mechanism and unaware
receivers do not enforce them. Deployment-wide enforcement cannot be
obtained from an unknown or unsupported DNSid flag; it must be
supplied by application policy or a deployment profile.
Initially defined flags:
Ihsanullah Expires 31 December 2026 [Page 17]
Internet-Draft DNSid June 2026
+========+===========================================+
| Flag | Description |
+========+===========================================+
| mtls | Verifiers MUST use mutual TLS for |
| | connections to this agent. |
+--------+-------------------------------------------+
| logchk | Verifiers MUST perform a log-inclusion |
| | check before any operation the deployment |
| | classifies as high-value or irreversible. |
+--------+-------------------------------------------+
Table 4
Example: fl=mtls,logchk
The "logchk" flag governs the policy-gated log-inclusion check
(Section 9.2); it is distinct from, and does not replace, the
mandatory bilateral ISSUANCE binding check (Section 9.1 step 5).
This specification does not classify which operations are high-value
or irreversible; that classification is a deployment or relying-party
policy matter.
5.7. KA (Key Age Maximum) Tag
The "ka" tag expresses the maximum acceptable age of the DNSid
operational signing key (the key discovered via "ku"). Verifiers
MUST reject operational keys older than the indicated age.
The "ka" value is an integer followed by a case-sensitive unit
suffix. Defined suffixes: "h" (hours) and "d" (days). Defined
values: 24h, 7d, 30d, 90d. Absence means no constraint. Unknown
values MUST be treated as a verification failure.
The operational key's age is computed from the timestamp of the
ISSUANCE or KEY_ROTATION event that introduced the key into the
lifecycle log. The lifecycle log is the authoritative source for key
lifecycle timestamps. If the "ka" tag is present and the verifier
cannot obtain the required lifecycle event or cryptographic proof,
key age verification MUST fail.
Accountable entity record-signing key age policy is out of scope for
this revision; future profiles MAY define separate mechanisms for
accountable entity key age constraints.
Ihsanullah Expires 31 December 2026 [Page 18]
Internet-Draft DNSid June 2026
5.8. Multi-String Encoding
DNS TXT RDATA is represented as one or more character-strings, each
limited to 255 octets ([RFC1035] Section 3.3). Implementations MUST
concatenate all strings within a single TXT RR before parsing tag-
value pairs. No separator is inserted at string boundaries.
Example (split across strings for readability). This is the self-
accounted case, where the DNSid is its own accountable entity ("gi"
equals the agent FQDN):
_dnsid.billing-agent-acme.example. 300 IN TXT (
"v=DNSid1; gi=billing-agent-acme.example; fl=mtls,logchk;"
"ek=https://billing-agent-acme.example/dnsid/entity-keys.json;"
"ku=https://billing-agent-acme.example/dnsid/op-keys.json;"
"lr=scitt:https://log.billing-agent-acme.example/entries/3f9a;"
"su=https://billing-agent-acme.example/dnsid/status;"
"sg=<base64url-encoded-signature>"
)
In a delegated deployment, where the DNSid operates under a distinct
accountable entity, "gi" names the external entity and "ek" resolves
under that entity's domain, while "ku" remains under the agent FQDN:
_dnsid.payroll.contractor.example. 300 IN TXT (
"v=DNSid1; gi=acme-corp.example; fl=mtls,logchk;"
"ek=https://acme-corp.example/dnsid/entity-keys.json;"
"ku=https://payroll.contractor.example/dnsid/op-keys.json;"
"lr=scitt:https://log.acme-corp.example/entries/77c1;"
"su=https://payroll.contractor.example/dnsid/status;"
"sg=<base64url-encoded-signature>"
)
In this delegated example the agent FQDN (payroll.contractor.example)
is not a subdomain of "gi" (acme-corp.example); the binding is
established by the bilateral ISSUANCE event, which records the "gi"
value (see Section 5.4 and Section 9.1).
6. Entity-Signed Record Integrity
6.1. Motivation
DNSSEC provides integrity for DNS records via a top-down signing
chain from the DNS root through TLD operators to the registrant's
zone. However, the TLD operator and higher-level signers hold keys
above the registrant's zone and could, in principle, modify records
without the registrant's knowledge or consent.
Ihsanullah Expires 31 December 2026 [Page 19]
Internet-Draft DNSid June 2026
DNSid is designed so that the accountable entity, not an intermediate
DNS operator, CA, or platform, remains the authority for the identity
declaration. DNSSEC and WebPKI strengthen resolution and endpoint
authentication, but the DNSid record signature and lifecycle events
preserve accountable-entity control over the identity state.
Depending solely on DNSSEC for integrity is therefore insufficient;
DNSid specifies an integrity mechanism in which the accountable
entity signs the DNSid record content with its own key.
DNSid record integrity is evaluated using two independent channels:
the DNS response carries the signed DNSid record, and the "ek" HTTPS
key service, whose host is the "gi" domain or a host under it,
supplies the public key used to verify the accountable entity's
signature. DNSSEC, when present, authenticates the DNS response
itself; the entity signature authenticates the accountable entity's
assertion over the record contents. These are independent integrity
properties: the entity signature protects against record content
modification regardless of DNSSEC state, while DNSSEC protects
against DNS response tampering in transit.
6.2. Signature Generation
The "sg" tag contains a signature computed as follows:
1. Construct the canonical record string by concatenating all tag-
value pairs EXCEPT the "sg" tag, in alphabetical order by tag
name, separated by semicolons, with no whitespace. The canonical
string is encoded as US-ASCII octets before signing.
2. Sign the canonical octet string using the accountable entity's
current record-signing key (the key published at the JWKS
endpoint referenced by the "ek" tag). The DNSid operational key
at "ku" MUST NOT be used to sign "sg".
3. Encode the signature as base64url ([RFC4648] Section 5) without
padding.
The signing algorithm is determined by the key's "alg" field in the
JWKS response. Implementations MUST support ES256 (ECDSA with P-256)
[RFC7518]; the ES256 signature is the fixed-width R||S form defined
by JWA ([RFC7518] Section 3.4), not an ASN.1 DER encoding.
Implementations SHOULD support Ed25519, whose signatures use the
JOSE/OKP representation defined for EdDSA in [RFC8037]. When post-
quantum algorithms are registered for use with JWS, implementations
SHOULD add support for ML-DSA (FIPS 204) [NIST-PQC].
Ihsanullah Expires 31 December 2026 [Page 20]
Internet-Draft DNSid June 2026
6.3. Signature Verification
A verifier:
1. Fetches the JWKS from the "ek" endpoint over HTTPS.
2. Reconstructs the canonical record string (all tags except "sg",
alphabetical order, no whitespace).
3. Verifies the "sg" value against the canonical string using the
public key from the "ek" JWKS.
4. If verification fails, the verifier MUST reject the record.
The key at "ku" MUST NOT be used to verify "sg". Successful "sg"
verification establishes record integrity under the accountable
entity's key named by "ek"; it does not by itself establish DNS-
origin authenticity for the _dnsid.<fqdn> owner name (see
Section 6.4) and does not establish that the DNSid operational
identity consented to the accountable entity (see Section 9 and the
ISSUANCE event in Section 8.4).
The live "ek" JWKS contains exactly one current record-signing key
(see Section 7.2); the verifier uses that key to verify "sg".
Signatures made by a superseded key are verified using key material
recorded in the lifecycle log (see Section 8.4), not the live
endpoint.
This section verifies record-content integrity only. A verifier that
relies on the DNSid-to-accountable-entity binding MUST perform the
bilateral binding check in Section 9.1 step 5. For record-integrity-
only processing, the verifier MAY additionally consult the lifecycle
log or applicable profile evidence to evaluate whether the record-
signing key or record has been superseded or revoked since the record
was last updated.
6.4. Relationship to DNSSEC
DNSSEC, when deployed, provides an independent integrity layer that
protects against on-path tampering of the DNS response. DNSid
implementations SHOULD deploy DNSSEC. Verifier behavior depends on
the DNSSEC state of the zone:
DNSSEC absent (zone not signed): Verification of the "sg" tag
against the accountable entity's key discovered via "ek" proves
that the TXT record content was signed by the key named by "ek".
By itself, this does NOT prove DNS-origin authenticity for the
_dnsid.<fqdn> owner name: an attacker who can modify
Ihsanullah Expires 31 December 2026 [Page 21]
Internet-Draft DNSid June 2026
unauthenticated DNS responses can substitute a different
apparently-valid record (published by a different accountable
entity), even though they cannot forge a "sg" value under the
original entity's key. Verifying "sg" also does NOT by itself
prove that the DNSid operational identity consented to the
accountable entity; that property requires the bilateral binding
check on the ISSUANCE event (see Section 9.1 step 5). Verifiers
SHOULD expose the DNSSEC state (absent, validated, or failed) in
their verification output. Deployment profiles or applications
that require DNS-origin authentication independent of WebPKI MAY
require DNSSEC and reject unsigned zones by local policy.
Verifiers relying on the DNSid-to-accountable-entity binding in
DNSSEC-absent zones SHOULD obtain log evidence for the ISSUANCE
event according to the applicable log-method binding. In this
profile the root of trust for the FQDN-to-key binding is WebPKI
(the certificate authorities that authenticate the "ek" and "ku"
HTTPS endpoints), together with the lifecycle log's bilateral
ISSUANCE binding, not the DNS hierarchy. The DNSSEC-absent
profile therefore provides WebPKI-assisted reduced assurance, not
DNS-rooted assurance.
DNSSEC present and valid: DNSSEC authenticates DNS-origin integrity
for the owner name, and "sg" verification confirms record content
integrity under the accountable entity's key named by "ek". This
is the strongest assurance level for the DNS surface; for the
DNSid-to-accountable-entity binding, a verifier additionally
performs the bilateral binding check on the ISSUANCE event when
required by local policy.
DNSSEC present but validation fails: The verifier MUST treat the
DNSid TXT record as unusable and abort verification. DNSSEC
validation failure means authenticated DNS data for the owner name
could not be established; the DNS response may have been tampered
with in transit. This follows the precedent set by DANE
([RFC6698] Section 4), which requires that TLSA records with
failed DNSSEC validation be treated as unusable.
These behaviors correspond to four named assurance modes: DNSSEC-
failed (record unusable); WebPKI-assisted reduced assurance (DNSSEC
absent); DNSSEC-authenticated (DNSSEC present and valid); and a
DNSSEC-authenticated high-assurance profile that additionally fails
closed and is optionally reinforced with DANE/TLSA ([RFC6698]) for
the key service (see Section 12). Across all modes the three claims
remain distinct: the entity signature ("sg") establishes record-
content integrity; DNSSEC establishes DNS-origin authenticity; and
the bilateral ISSUANCE event establishes the DNSid-to-accountable-
entity binding.
Ihsanullah Expires 31 December 2026 [Page 22]
Internet-Draft DNSid June 2026
7. HTTP Service Interfaces
DNSid defines three HTTPS service interfaces referenced by the TXT
record: the operational key service ("ku"), the entity key service
("ek"), and the status service ("su"). These interfaces are
abstract: the specification defines the semantics and required
response properties, not a specific API schema. Their URLs are
carried in full in the TXT record; DNSid does not define or register
a ".well-known" URI, and any paths shown in examples are
illustrative. Interoperable HTTP response schemas are specified by
deployment profiles or companion specifications.
7.1. Operational Key Service (KU endpoint)
The "ku" endpoint exposes the DNSid's operational (runtime) signing
keys. These keys are used for runtime challenge-response, agent
message signing, profile-defined content signing, and lifecycle-event
countersignatures attributed to the DNSid (such as the initial
operational-key countersignature on ISSUANCE; see Section 8.4). The
key at "ku" MUST NOT be used to verify the "sg" tag on the DNSid TXT
record; record-integrity verification uses the "ek" endpoint
(Section 7.2).
The endpoint MUST return a JWK Set ([RFC7517]) over HTTPS. The
response:
* MUST include at least one signing key with a "kid" (key ID).
* MUST include the "alg" field on each key, enabling algorithm
negotiation for crypto agility.
* SHOULD include key metadata such as expiry and key operations, to
support local policy evaluation.
* MUST be served over HTTPS with a valid TLS certificate presenting
a dNSName SAN (DNS-ID, [RFC9525]) that matches the agent FQDN.
The "ku" URI host MUST be the agent FQDN.
If the key service response does not satisfy these requirements,
verification of operations relying on the operational key MUST fail.
Ihsanullah Expires 31 December 2026 [Page 23]
Internet-Draft DNSid June 2026
A dedicated DNSid key-service endpoint is RECOMMENDED so that the
exactly-one-current-key requirement above is unambiguous. An agent
MAY reuse an existing JWKS endpoint published at its FQDN for other
purposes (e.g., OAuth) only if the JWKS presented to DNSid verifiers
contains exactly one JWK usable for the relevant DNSid operation, so
that the verifier performs no selection among multiple candidate
keys. Endpoints that serve several keys for unrelated purposes are
unsuitable for direct reuse.
Future specifications MAY define additional key discovery profiles,
including DNSSEC-authenticated delegated key services, parent-domain
key services, DNS-carried key material, or log-bound key references.
Such profiles MUST specify how the binding between the agent FQDN and
the signing key is authenticated without relying solely on a
signature verified by the key being discovered. A verifier MUST NOT
use an alternate key discovery mechanism unless the applicable
profile defines its verification requirements and failure behavior.
The live JWKS at "ku" MUST contain exactly one current DNSid
operational signing key in the base profile. Superseded operational
keys MUST NOT be served at this endpoint; verification of signatures
made by a superseded operational key uses key material recorded in
the lifecycle log (see Section 8.4), not the live endpoint. Multi-
current-key operation (for example, during a post-quantum or multi-
algorithm transition) is reserved for a future profile. The base
profile intentionally trades transition flexibility for unambiguous
current-key validation.
The signing algorithm for all DNSid operations is declared by the
"alg" field of the JWK published at the key service endpoint. The
DNSid TXT record itself does not encode algorithm information;
algorithm negotiation occurs entirely through the JWKS.
Implementations MAY optionally reinforce the key service binding with
DANE ([RFC6698]) TLSA records (certificate usage 3, DANE-EE) for
cryptographic binding between the FQDN and the TLS certificate,
eliminating dependence on external certificate authorities.
7.2. Entity Key Service (EK endpoint)
The "ek" endpoint exposes the accountable entity's record-signing
keys. The key discovered via "ek" verifies the "sg" tag on the DNSid
TXT record and verifies accountable-entity signatures on lifecycle
events.
The endpoint MUST return a JWK Set ([RFC7517]) over HTTPS. The
response:
Ihsanullah Expires 31 December 2026 [Page 24]
Internet-Draft DNSid June 2026
* MUST include at least one signing key with a "kid" (key ID).
* MUST include the "alg" field on each key.
* SHOULD include key metadata such as expiry and key operations.
* MUST be served over HTTPS with a valid TLS certificate presenting
a dNSName SAN (DNS-ID, [RFC9525]) that matches the "ek" URI host.
The "ek" URI host MUST be the domain identified by "gi" or a host
under that domain; see Section 5.4 for the consistency rule.
The "ek" URI host is not required to match the agent FQDN. In
delegated deployments, "ek" typically resolves under the accountable
entity's domain rather than under the agent FQDN.
If the key service response does not satisfy these requirements, "sg"
verification MUST fail.
The live JWKS at "ek" MUST contain exactly one current accountable-
entity record-signing key in the base profile. Superseded keys MUST
NOT be served at this endpoint; verification of prior records and
historical lifecycle events uses the key material recorded in the
lifecycle log (see Section 8.4), not the live endpoint. The
algorithm for "sg" generation is declared by the "alg" field of the
JWK at the "ek" endpoint.
7.3. Status Service (SU endpoint)
The status service endpoint MUST return the agent's current lifecycle
state over HTTPS. The response:
* MUST include the current state (see Section 10.1 for valid states:
PENDING, PROVISIONING, VERIFYING, ACTIVE, RETIRED, or REVOKED).
* MUST include the timestamp of the last state transition.
* MUST include a reason code when the state is REVOKED.
* MUST be served over HTTPS with a valid TLS certificate presenting
a dNSName SAN (DNS-ID, [RFC9525]) that matches the "su" URI host.
If the status service response does not satisfy these requirements,
interactive verification MUST fail.
Status freshness and failure handling: for interactive verification
the verifier MUST obtain a status response fresh enough under local
policy and MUST confirm the state is ACTIVE. If the status endpoint
is unreachable or returns a transport-level error, the DNSid
Ihsanullah Expires 31 December 2026 [Page 25]
Internet-Draft DNSid June 2026
verification result for new interactive operations is INDETERMINATE
and the verifier MAY retry. If the endpoint returns a state other
than ACTIVE, or a response older than the verifier's freshness bound,
the DNSid verification result FAILS. A verifier MUST NOT report a
DNSid identity as verified-ACTIVE when current status is unavailable
or stale. These rules govern only the DNSid verification result; an
application MAY apply its own risk-based fail-open or fail-closed
policy, but only outside of, and clearly distinguished from, the
DNSid verification result.
The status endpoint is the primary real-time mechanism for obtaining
the accountable entity's current lifecycle-state declaration. It is
the accountable entity's own declaration, not a globally trusted
authority. Firewalls, IAM systems, policy engines, and other Layer
3-7 systems MAY reference this declaration when making their own
trust decisions.
A status URL whose host lies outside the registrant-controlled "gi"
origin can still provide useful operational status, but a verifier
SHOULD treat such off-"gi" status as delegated operational status
rather than a direct accountable-entity declaration, unless the
delegation is authenticated by the DNSid record contents, DNSSEC, or
another specified mechanism. Accountable-entity-signed status
delegation is left to a future profile.
DNSid does not enforce revocation. A verifier's trust in the status
endpoint is a matter of local policy. High-assurance deployments MAY
require consistency between the status endpoint and the lifecycle
log, MAY require log or witness consistency, or MAY require status
responses to be countersigned by a designated authority.
7.4. Private and Access-Controlled Deployments
The "ek", "ku", and "su" endpoints are the accountable entity's
identity endpoints, not the agent's functional service endpoint.
They MAY be access-controlled or reachable only within a private
network. In such deployments, only verifiers with the necessary
access can perform interactive verification; verifiers without access
obtain an INDETERMINATE result for interactive operations but can
still perform historical or record verification from log evidence
(see Section 9). DNSid does not require the agent or its identity
endpoints to be publicly reachable or discoverable.
Ihsanullah Expires 31 December 2026 [Page 26]
Internet-Draft DNSid June 2026
8. Abstract Log Interface
DNSid requires an append-only verifiable log for lifecycle history.
This section defines the abstract interface that any conforming log
implementation must satisfy. It does not specify a particular log
technology.
8.1. Log Identification
The "lr" tag in the DNSid TXT record identifies the log using a
structured reference. The method component identifies the log
binding. The remaining components locate the agent's entry within
that log.
Conforming log implementations SHOULD register their method name with
the DNSid Log Method Registry (Section 14).
Concrete log bindings SHOULD be documented as separate specification
documents, analogous to W3C DID method specifications. Each binding
document defines the method name, reference syntax, entry format,
proof format, and query interface for a specific log technology. The
DNSid Log Method Registry serves as the index for registered
bindings.
Interoperable lifecycle verification for a given log method therefore
depends on that method's registered binding; an implementation that
claims support for an "lr" method MUST implement the method's
registered binding. This document does not define a concrete
binding. A transparency-log binding, for example a SCITT-based
binding ([I-D.ietf-scitt-architecture]), is one candidate and would
be specified separately. A log method without a registered binding
is deployment-specific and does not provide interoperable
verification for DNSid verifiers unless the relying parties share an
out-of-band method specification.
8.2. Required Properties
A conforming log MUST provide:
* Append-only: entries cannot be modified or deleted after
recording.
* Cryptographic inclusion proofs: for any recorded entry, the log
can produce a proof that the entry is included in the log at a
specific position.
* Verifiable timestamps: each entry has a timestamp that is
independently verifiable.
Ihsanullah Expires 31 December 2026 [Page 27]
Internet-Draft DNSid June 2026
* Verifier accessibility: verifiers within the log's declared
verification scope can obtain lifecycle entries or portable
cryptographic proofs sufficient to verify inclusion, timestamps,
and key-continuity history. Current ACTIVE or REVOKED state is
obtained from the status service (see Section 7.3); a log method
supplies current-state evidence only if it explicitly defines
freshness and non-revocation semantics.
* Durability: entries persist independently of the log operator's
continued participation.
The accountable entity selects the log technology and its
verification scope. A log MAY be public, consortium-scoped, private,
access-controlled, or based on portable receipts, provided that
verifiers expected to rely on the DNSid can obtain sufficient
cryptographic evidence to perform verification. A publicly queryable
log provides the broadest interoperability and is RECOMMENDED for
agents intended for open Internet-scale verification.
This specification defines the semantic event fields and required
signer roles for each event type (Section 8.4). It does NOT define a
universal encoding, canonicalization, inclusion-proof format, or
byte-level layout for lifecycle events. Each registered log method
(Section 14) MUST specify the concrete event encoding, the
canonicalization procedure used to construct the signed bytes, the
placement and format of signatures and countersignatures, and the
inclusion or finality proof format. Verifiers MUST apply the
canonicalization and proof rules of the log method named by "lr" when
verifying signed event payloads.
8.3. Entry Signing
Lifecycle event entries MUST be signed by the authorizing key
specified for each event type. For all events except KEY_ROTATION,
this is the accountable entity's record-signing key (the key
discovered via the "ek" JWKS endpoint; see Section 7.2), ensuring
that the accountable entity, not a third party, is the author of the
record.
KEY_ROTATION events are an exception: because they rotate the DNSid
operational key, and routine operational-key maintenance is
deliberately designed not to require the accountable entity record-
signing key, a KEY_ROTATION event is authorized by the previous
operational key rather than by the accountable entity key (see
Section 8.4). The log method records and witnesses the event's
inclusion. All other lifecycle events MUST carry the accountable
entity signature.
Ihsanullah Expires 31 December 2026 [Page 28]
Internet-Draft DNSid June 2026
For lifecycle events that carry an accountable-entity signature, that
signature MUST be verified against the record-signing key material or
durable reference recorded in the ISSUANCE event (see Section 8.4),
not against whatever the live "ek" JWKS endpoint currently serves.
This makes historical lifecycle verification independent of mutable
endpoint state. Profiles that define accountable entity key
continuity MAY relax this rule.
ISSUANCE events MUST additionally be countersigned by the DNSid's
initial operational key (see Section 8.4 ISSUANCE). The
countersignature establishes the DNSid's consent to the accountable
entity recorded by ISSUANCE and is verified against the initial
operational key material recorded in the same event.
Entries MAY additionally be countersigned by the log operator or a
witness service. Such countersignatures provide additional assurance
but do not replace the required event-specific authorizing
signature(s).
8.4. Event Types
Lifecycle events that introduce or rotate signing keys MUST preserve
sufficient public key material, or a durable reference to such
material, to support historical signature verification independent of
the current JWKS endpoint. A key hash or thumbprint MAY be included
for compact binding, but a hash alone is not sufficient for
historical signature verification.
The log MUST support recording the following core event types. Each
event includes the agent FQDN, event type, timestamp, the authorizing
signature(s) specified for that event type, and event-specific data:
ISSUANCE: Agent FQDN, governance identifier ("gi"), initial DNSid
operational public key material or durable public-key reference
(with thumbprint, "kid", and "alg"), initial accountable entity
record-signing public key material or durable public-key reference
(with thumbprint, "kid", and "alg"), timestamp. Recorded when an
accountable entity adopts a DNSid operational key and publishes a
DNSid TXT record for it. The agent and its operational keypair
MAY exist prior to ISSUANCE; ISSUANCE is the adoption/binding
event, not necessarily the agent's creation. The ISSUANCE event
MUST be signed by the accountable entity's record-signing key and
MUST be countersigned by the initial DNSid operational key. Both
signatures cover the same canonical ISSUANCE content. The
accountable entity signature is verified against the accountable
entity record-signing key material/reference recorded in this
event; the DNSid operational-key countersignature is verified
against the initial operational key material/reference recorded in
Ihsanullah Expires 31 December 2026 [Page 29]
Internet-Draft DNSid June 2026
this event. Recording both keys in the event itself makes
historical verification of the ISSUANCE binding independent of
mutable JWKS endpoint state.
KEY_ROTATION: Previous operational public key thumbprint, new
operational public key material or durable public-key reference,
new operational public key thumbprint, rotation timestamp.
Recorded when the DNSid's operational signing key (the key
discovered via "ku") changes. Establishes continuity: same DNSid,
new operational key. The KEY_ROTATION event MUST be signed by the
previous operational key. The signed payload MUST cover at least
the agent FQDN, the previous operational public key thumbprint,
the new operational public key material or durable reference, the
new operational public key thumbprint, the rotation timestamp, and
the event type; a signature over only a thumbprint is
insufficient. This previous-key authorization proves continuity
from the prior operational key to the new one and makes silent key
replacement detectable. It does not by itself defend against a
compromised previous operational key; operational-key compromise
is addressed by accountable-entity revocation and status (see
Section 12.8). An accountable entity signature is NOT required on
KEY_ROTATION. The concrete signature placement and the inclusion
or finality proof are defined by the applicable log-method binding
(see Section 10.3).
REVOCATION: Reason code (REQUIRED), timestamp. Recorded when the
agent's identity is forcibly ended. Permanent and irreversible.
Reason codes follow X.509 conventions: keyCompromise,
policyViolation, superseded, cessationOfOperation. Signed work
products from the period triggering revocation SHOULD be treated
as suspect by verifiers.
RETIREMENT: Timestamp. Recorded when the agent's identity lifecycle
is gracefully completed. The agent was decommissioned as planned;
signed work products produced before retirement are not
invalidated solely by retirement. Permanent and irreversible.
MIGRATION: Previous log reference, new log reference, final entry
reference on previous log, timestamp. Recorded on the NEW log
when an agent's lifecycle history is moved between log
technologies. The previous log's records remain the authoritative
history for events before the migration timestamp. The new log's
first entry MUST reference the agent's final entry on the previous
log.
The log MAY additionally support the following OPTIONAL event types:
DELEGATION: Delegating agent FQDN, delegatee agent FQDN, scope
Ihsanullah Expires 31 December 2026 [Page 30]
Internet-Draft DNSid June 2026
constraints, expiry. Recorded when one agent grants authority to
another.
Additional event types MAY be defined in companion specifications.
9. Verification Protocol
DNSid verification combines DNS resolution, accountable entity
signature validation, TLS-based live identity, and optional log
queries.
9.1. Interactive Verification
1. The verifier queries _dnsid.<target-fqdn> for TXT records. If
multiple TXT records are present, verification MUST fail. The
verifier concatenates all strings in the TXT RDATA and parses the
tag-value record.
2. The verifier validates that "v=DNSid1" is the first tag and that
all REQUIRED tags are present and non-empty.
3. The verifier fetches the JWKS from the "ek" endpoint over HTTPS
and verifies the accountable entity's signature ("sg" tag)
against the canonical record content (Section 6.3). If signature
verification fails, the record MUST be rejected. Successful "sg"
verification establishes record integrity under the accountable
entity's key named by "ek"; it does not by itself establish that
the DNSid operational identity consented to that accountable
entity. Verifiers that rely on the DNSid-to-accountable-entity
binding MUST additionally perform the bilateral binding check
described in step 5.
4. The verifier establishes an HTTPS or mTLS connection with the
agent at its FQDN (not at _dnsid.<fqdn>). The TLS handshake and
certificate chain establish an authenticated TLS connection to a
peer presenting a certificate valid for the agent FQDN under the
verifier's WebPKI policy. This does not by itself establish DNS-
origin authenticity or durable accountability. When mTLS is
required (the "mtls" flag is present), the verifier MUST validate
the peer certificate against the agent FQDN per [RFC9525]. DNSid
does not define the application protocol or runtime
authentication exchange.
5. Bilateral binding check. A verifier that relies on the DNSid-to-
accountable-entity binding MUST retrieve the ISSUANCE event for
this DNSid from the log identified by "lr" and verify:
Ihsanullah Expires 31 December 2026 [Page 31]
Internet-Draft DNSid June 2026
* Both signatures on the ISSUANCE event: the accountable entity
signature (verified against the accountable entity record-
signing key material/reference recorded in the event), and the
DNSid operational-key countersignature (verified against the
initial operational key material/ reference recorded in the
event).
* That the ISSUANCE event under evaluation corresponds to the
DNSid TXT record under evaluation: same DNSid FQDN, same "gi"
value, and the accountable entity record-signing key material/
reference recorded in ISSUANCE corresponds to the key
discovered via the current "ek" endpoint (a future profile
defining accountable entity key continuity MAY relax this).
* That the operational key currently published at "ku" is either
the initial operational key recorded in ISSUANCE, or is
connected to that initial key by continuity evidence defined
by the applicable log-method binding or profile (typically a
chain of KEY_ROTATION events).
If any of these checks fails, the bilateral binding MUST be
treated as unverified. Concrete event encoding,
canonicalization, and proof reconstruction follow the log method
named by "lr"; this base specification does not define a
universal event serialization.
This bilateral binding check is independent of the "logchk"
policy flag; "logchk" governs log-inclusion checks for high-value
operations (see Section 9.2), not bilateral binding verification.
Before relying on a DNSid identity for a new interactive operation,
the verifier MUST query the status service ("su" tag) over HTTPS,
obtain a response fresh enough under local policy, and confirm the
state is ACTIVE. An unavailable or stale status yields an
INDETERMINATE or failed result as specified in Section 7.3; the
verifier MUST NOT proceed as if the state were ACTIVE. What
constitutes a "new interactive operation", and any status caching
bound, are local-policy or deployment-profile matters. A verifier
MAY skip the status lookup only when performing offline or historical
verification.
These steps provide interactive identity assurance: the verifier
establishes that the agent has a current ACTIVE accountable-entity
assertion with verified binding evidence.
Ihsanullah Expires 31 December 2026 [Page 32]
Internet-Draft DNSid June 2026
9.2. Historical Verification
Step 6 (Log Verification): For high-assurance operations, or when the
"logchk" flag is present, the verifier queries the lifecycle log
identified by the "lr" tag. The verifier checks:
* That the agent's ISSUANCE event is recorded and that any required
log-method inclusion proofs are valid (this is in addition to the
bilateral binding check performed in step 5, which verifies
signatures on the ISSUANCE event itself).
* That the current operational signing key is bound to this agent
FQDN, either as the initial operational key recorded in ISSUANCE
or via a verifiable continuity chain defined by the applicable
log-method binding or profile.
* That the log binding provides evidence of the agent's non-revoked
state at the relevant verification time.
Work-product provenance and content-signature receipt profiles are
outside this base specification and may be defined by companion
specifications.
When log verification is required by local policy, by the "logchk"
flag, or by the risk profile of the operation, failure to obtain the
required log entry or cryptographic proof MUST cause log verification
to fail.
Historical verification provides lifecycle transparency. These
checks are used for audit, compliance, post-incident forensics, and
evaluating agent identity evidence associated with cross-
organizational outputs.
10. Lifecycle Events
10.1. Agent States
An agent identity progresses through a linear state machine. Each
transition is a log event.
PENDING --> PROVISIONING --> VERIFYING --> ACTIVE
|
[key rotation]
[delegation]
/ \
/ \
RETIRED REVOKED
(graceful end) (forced end + reason)
Ihsanullah Expires 31 December 2026 [Page 33]
Internet-Draft DNSid June 2026
* PENDING: Identity record created, infrastructure not yet deployed.
* PROVISIONING: Cryptographic challenge issued by the accountable
entity or its provisioning system.
* VERIFYING: Challenge signed by the agent's private key; the
accountable entity or its provisioning system is validating the
response.
* ACTIVE: Operational. Key rotation and delegation occur within
this state.
* RETIRED: Graceful end-of-life. The agent completed its intended
lifecycle and was decommissioned as planned. Signed work products
produced before retirement are not invalidated solely by
retirement.
* REVOKED: Forced end. Reason code REQUIRED (keyCompromise,
policyViolation, superseded, cessationOfOperation). Signed work
products from the period triggering revocation SHOULD be treated
as suspect by verifiers.
Both RETIRED and REVOKED are terminal states. Transitions are
forward-only. Neither can return to ACTIVE. A new identity
registration is required.
10.2. Identity Lifecycle Flexibility
DNSid may be attached to agents at any point in their lifecycle,
including agents that were deployed before DNSid was available. The
PENDING state serves as the entry point for registration regardless
of when the agent was originally created or how long it has been
operational.
For fleets of pre-existing agents, organizations may migrate agents
to DNSid incrementally. No flag-day deployment is required; agents
can be registered individually or in batches as operational needs
dictate.
Ihsanullah Expires 31 December 2026 [Page 34]
Internet-Draft DNSid June 2026
An agent's DNSid may be replaced. The previous DNSid enters RETIRED
or REVOKED as appropriate, and a new ISSUANCE event creates a fresh
identity with its own log history. The new identity carries no
history from the previous one. Verifiers will observe the new
identity's short effective history, which is itself a trust-relevant
signal: an identity with no log depth is distinguishable from one
with years of operational history. Replacement may serve legitimate
operational purposes (organizational restructuring, key compromise
response, rebranding) but cannot import the previous identity's
accumulated trust.
10.3. Key Rotation Procedure
KEY_ROTATION rotates the DNSid operational key (the key discovered
via "ku"). Routine operational-key rotation proceeds as follows:
1. The agent generates a new operational key pair.
2. The new key is published to the "ku" JWKS endpoint as the single
current operational key. The previous key MUST NOT be retained
at the endpoint; verification of outstanding signed work products
uses key material recorded in the lifecycle log (see
Section 8.4).
3. A KEY_ROTATION event is recorded in the lifecycle log, binding
the previous public key thumbprint to the new public key material
or durable public-key reference and the new public key
thumbprint, establishing continuity of the DNSid operational
identity.
4. If the rotation does not change any TXT tag value (for example,
the "ku" URI is unchanged because only the JWKS contents at the
existing URI changed), the DNSid TXT record need not be re-
signed. If the rotation changes any TXT tag value (including the
"ku" URI itself), the TXT record MUST be re-signed by the
accountable entity's current record-signing key (the key
discovered via "ek"), and DNS TTL expiry propagates the updated
record to verifiers.
Ihsanullah Expires 31 December 2026 [Page 35]
Internet-Draft DNSid June 2026
The KEY_ROTATION event MUST be signed by the previous operational key
over the new key, as specified in Section 8.4; this previous-
operational-key authorization is the base continuity mechanism and
does not involve the accountable entity record-signing key. A
profile MAY require additional consent (for example, an accountable
entity countersignature) but MUST NOT weaken the previous-key
authorization. The concrete signature placement and the inclusion or
finality proof are defined by the applicable log-method binding
(Section 8). Verifiers that require continuity from ISSUANCE to the
current operational key evaluate the lifecycle log according to the
applicable log-method binding.
Verifiers encountering a signature from a previous operational key
SHOULD check the lifecycle log for a KEY_ROTATION event linking the
previous key thumbprint to the current key before rejecting the
signature.
Changes to the accountable entity record-signing key (the key
discovered via "ek") or to the accountable entity itself are not
continuity-preserving in this base specification. Continuity of
accountable entity record-signing keys, transfer of accountability
between entities, and recovery from key loss are reserved for future
profiles. If any TXT tag changes (including "ek" or "gi"), the TXT
record MUST be re-signed by the accountable entity's current record-
signing key discovered via the resulting record's "ek". Historical
verification of the original ISSUANCE event continues to use the key
material/reference recorded in that event. Verifiers MAY treat an
"ek" or "gi" change without a profile-defined continuity proof as
reissuance or as a local-policy risk signal.
10.4. Status Change Propagation
When an agent's status changes (e.g., revocation), the change
propagates through:
* Status endpoint (su): reflects the new state immediately.
* Log record (lr): permanent record with reason code.
* DNS TTL expiry: verifiers re-resolve the DNSid TXT record on the
next TTL cycle.
Systems that reference this identity (firewalls, IAM, policy engines,
audit platforms) independently discover the status change on their
own schedule. DNSid reflects the accountable entity's decision.
Enforcement is the responsibility of each consuming system.
Ihsanullah Expires 31 December 2026 [Page 36]
Internet-Draft DNSid June 2026
11. Applicability
DNSid applies to any agent that can be assigned an FQDN and whose
accountable entity can publish the verification material defined in
this document. Public discoverability of the agent is not required:
DNSid is independent of any agent-discovery mechanism, and it neither
requires nor provides discovery. In particular, DNSid applies to
agents that are not publicly discoverable, that expose no functional
service endpoint, that are reachable only within a private network,
or that have been retired. The accountability and ownership history
persist after the agent itself is gone.
Verification scope follows from reachability. Interactive
verification requires the agent's FQDN and the relevant identity
endpoints to be reachable to that verifier and a fresh ACTIVE status
(see Section 9.1); a verifier without that reachability obtains an
INDETERMINATE result for interactive operations. Historical
verification proceeds from lifecycle-log evidence and does not
require the agent to be running or reachable, but cannot conclude the
agent's current ACTIVE status.
Even agents operating within a single trust domain may transcend
organizational boundaries as their work products, signed outputs, and
downstream interactions propagate beyond their origin. The zero-
trust security model, which treats internal and external trust
boundaries equivalently, provides independent motivation for applying
durable cross-organizational identity even to agents that currently
operate within a single trust domain.
12. Security Considerations
12.1. Entity Signature and DNSSEC
Risk: An on-path attacker modifies the DNSid TXT record during DNS
resolution. Mitigation: layered integrity properties operating on
different channels. The accountable entity's signature ("sg" tag)
binds record content to the accountable entity's record-signing key
(discovered via "ek"). DNSSEC, when deployed, provides DNS data
origin authentication and integrity for the DNS response. These are
independent: "sg" protects against record content modification under
the entity's key, regardless of DNSSEC state; DNSSEC protects against
DNS response tampering and substitution. When DNSSEC validation
fails, the record MUST be treated as unusable (Section 6.4). When
DNSSEC is absent, "sg" verification under "ek" remains the record-
content integrity mechanism, but does not by itself establish DNS-
origin authenticity for the _dnsid.<fqdn> owner name; verifiers
requiring DNS-origin authentication independent of WebPKI SHOULD
require DNSSEC by local policy. Verifiers relying on the DNSid-to-
Ihsanullah Expires 31 December 2026 [Page 37]
Internet-Draft DNSid June 2026
accountable-entity binding additionally perform the bilateral binding
check on the ISSUANCE event (Section 9.1 step 5), which does not
depend on DNSSEC state.
DNSid's entity signature is related to, but distinct from, domain
control validation ([I-D.ietf-dnsop-domain-verification-techniques]):
domain control validation proves control of a DNS zone at a point in
time, whereas the entity signature binds the record content to a
specific accountable-entity key. A deployment MAY use domain control
validation as a prerequisite for accepting a DNSid record from a new
registrant; this is a local-policy choice, not a protocol requirement
of this document.
12.2. Two-Key Separation
The DNSid TXT record cleanly separates two key roles:
* The accountable entity record-signing key (discovered via "ek")
signs the TXT record and all lifecycle events except KEY_ROTATION.
* The DNSid operational key (discovered via "ku") signs runtime
challenges, agent message signatures, profile-defined content
signatures, the ISSUANCE countersignature, and KEY_ROTATION
authorizations.
Compromise of the operational key allows runtime impersonation of the
DNSid but does NOT enable an attacker to publish a forged "sg" value
over a modified record; only the accountable entity record-signing
key can do so. Compromise of the accountable entity record-signing
key enables forging or substituting the TXT record content under that
entity's name but does NOT by itself enable runtime impersonation; an
attacker still needs the operational key to respond to runtime
challenges. Verifiers relying on the DNSid-to-accountable-entity
binding can also detect a forged TXT record (one whose ISSUANCE event
signatures do not verify against the ISSUANCE-recorded keys, or whose
recorded keys do not correspond to the keys currently discovered via
"ek" and "ku") through the bilateral binding check.
The keys in these two roles MUST be distinct key material. A
verifier MUST reject a record in which the current "ek" record-
signing key and the current "ku" operational key are the same public
key (specifically, identical JWK Thumbprints as defined by
[RFC7638]), unless a future profile explicitly defines a constrained
exception. This requirement holds even when the DNSid is self-
accounted: a verifier MUST NOT infer self-accounting from equality of
the "ek" and "ku" keys, because self-accounting is determined by the
"gi"-to-agent-FQDN relationship (see Section 5.4), not by key reuse.
Ihsanullah Expires 31 December 2026 [Page 38]
Internet-Draft DNSid June 2026
Continuity-preserving recovery from key loss or compromise is not
specified by this base revision and is reserved for future profiles;
revocation and status handling are described below.
12.3. TXT Record Ambiguity
Unlike a dedicated RR type, TXT records provide no inherent type
safety. Verifiers MUST validate the "v=DNSid1" version tag and MUST
reject any TXT record at the _dnsid owner name that does not contain
this tag. The singleton TXT requirement is a deliberate ambiguity-
control measure: verifiers do not select among multiple candidate
DNSid records and do not merge fields across records.
12.4. TTL and Caching
Stale DNSid TXT records create a window during which revoked or
rotated identities remain cached by resolvers. DNS is not a real-
time revocation channel. Operators SHOULD choose DNSid TXT TTLs
appropriate to the risk profile of the agent and SHOULD avoid long-
lived TTLs for identities that require responsive revocation.
Verifiers that require current lifecycle state MUST query the status
service rather than relying solely on cached DNS data.
12.5. Record Absence and Negative Caching
The absence of a "_dnsid" record means only that no DNSid assertion
was found for that name; it is not proof that no agent exists or that
the operating entity is unaccountable. A verifier treats absence as
"no DNSid assertion available," not as a negative attestation.
DNS negative caching ([RFC2308]) can delay recognition of a newly
published DNSid record: a resolver that cached a prior negative
answer may continue to report the name as absent until that cache
entry expires. Publishers should account for this propagation delay
when bringing a DNSid online, for example by keeping the zone's
effective negative-caching TTL (derived from the SOA TTL and SOA
MINIMUM field, per [RFC2308]) modest for names intended to carry
DNSid records.
12.6. Post-Quantum Considerations
Agent identity credentials are long-lived governance artifacts, not
ephemeral session tokens, the class of credential most vulnerable to
future quantum-capable signature forgery. Both key services
(Section 7.1 and Section 7.2) support algorithm negotiation via the
JWK "alg" field, enabling transition to post-quantum signature
algorithms (FIPS 204 ML-DSA, FIPS 205 SLH-DSA) without protocol
changes, consistent with the NIST IR 8547 deprecation timeline
Ihsanullah Expires 31 December 2026 [Page 39]
Internet-Draft DNSid June 2026
[NIST-IR-8547].
DNSid publishes key references ("ek", "ku") rather than inline public
key material, and this is a deliberate design choice. Key sizes vary
widely across post-quantum suites: some have kilobyte-scale public
keys (for example, ML-DSA), and some have much larger signatures and
associated metadata, while others have compact public keys (SLH-DSA
public keys are tens of bytes). Requiring public key material in the
TXT record would couple the DNS wire format to algorithm-specific
size assumptions and make DNSid fragile with respect to response
size, DNSSEC overhead, caching, transport fallback, and future crypto
agility. Keeping DNS as a small binding and rendezvous layer, with
key material behind explicit HTTPS key references, keeps the wire
format stable across algorithm transitions.
This rationale concerns public key material only. DNSid still
carries the record signature ("sg") inline in the TXT record, and
post-quantum signatures can themselves be large (notably SLH-DSA);
post-quantum signature size in the record is a separate design and
deployment consideration that key references do not address.
A future profile MAY define either of two distinct, optional,
algorithm-constrained mechanisms: (a) inline key material, which
allows verification without a key fetch but is usable only for suites
whose keys are compact enough for DNS; or (b) a key thumbprint or
digest selector, whose DNS size is determined by the selected digest
rather than by the public-key algorithm, and which identifies or
constrains the key fetched from the key service (and could
disambiguate a shared key service). Neither is part of the base
profile.
12.7. Log Durability
Organizations SHOULD choose log technologies with strong durability
guarantees and broad operational support. The MIGRATION event type
(Section 8.4) provides a mechanism for moving to a new log while
preserving history. Organizations SHOULD maintain an offline archive
of their log entries as a backup against log unavailability.
If a log becomes permanently unavailable, the agent's historical
provenance is degraded. The current DNS, JWKS, and status checks MAY
still be evaluated, but the DNSid-to-accountable- entity binding,
operational-key continuity, key-age ("ka"), the "logchk" inclusion
check, and historical verification are unavailable unless the
verifier holds cached or archived log evidence, and even then only
subject to freshness and local policy: cached evidence can support
ISSUANCE, history, and continuity but cannot establish fresh
revocation or non-revocation state. When acceptable cached or
Ihsanullah Expires 31 December 2026 [Page 40]
Internet-Draft DNSid June 2026
archived evidence is unavailable or stale, a verifier relying on the
binding MUST treat the result as reduced or indeterminate rather than
verified. If sufficient archived evidence for the previous log's
final entry is retained, the MIGRATION event allows re-establishing
historical continuity on a new log by referencing that final entry.
12.8. Revocation and Accountability
A REVOCATION event is an abnormal lifecycle state transition,
distinct from RETIREMENT. Whereas RETIREMENT indicates a planned or
graceful end of an agent identity, REVOCATION indicates that the
accountable entity has declared the identity no longer valid because
of a condition such as key compromise, policy violation,
supersession, or cessation of operation.
A REVOCATION event does not by itself repudiate all prior actions by
the agent, nor does it remove accountability for actions that
occurred before the revocation event. However, revocation is a
material trust signal. Verifiers and investigators evaluating prior
work products SHOULD consider the revocation reason, the artifact
timestamp, the status transition timestamp, the log event timestamp,
the relevant key history, and any available external evidence.
Signed work products produced during a suspected compromise or
policy-violation window SHOULD be treated as suspect by verifiers.
Work products produced before that window MAY retain provenance value
if the verifier can establish that the relevant signing key was valid
at the time of production and that no applicable revocation or
compromise event affects the artifact.
The two-key design preserves an accountable-entity-controlled
revocation path. If the operational key is compromised, the
accountable entity can revoke the DNSid and update status without
relying on the compromised operational key, because the operational
key ("ku") cannot authorize changes to the accountable entity key
("ek") or publish a forged "sg". This is revocation, not rotation:
base KEY_ROTATION requires the previous operational key, so the
accountable entity cannot perform a continuity-preserving rotation
without it. This is the recovery path for operational-key
compromise, including a compromised previous operational key that
authorizes a fraudulent KEY_ROTATION: the accountable entity records
a REVOCATION and updates status. Revocation is bounded by a
propagation window (status-endpoint freshness, DNS TTL expiry, and
how promptly a relying party re-checks status and the log). It is
therefore effective shortly after detection and propagation, not
instantaneously. Re-establishing operation after such a revocation
is out of scope for the base profile: continuity- preserving recovery
without the previous operational key is reserved for a future profile
Ihsanullah Expires 31 December 2026 [Page 41]
Internet-Draft DNSid June 2026
(see Section 12.10), and reissuing the agent without the old key
produces a new identity by local policy, not continuity-preserving
DNSid history.
12.9. URI Integrity
The HTTPS endpoints referenced by "ek", "ku", "su", and "cu" tags
depend on TLS [RFC8446] for integrity. All URI values in DNSid tags
MUST conform to [RFC3986]. Implementations MUST verify TLS
certificates for each HTTPS fetch and MUST NOT follow redirects to
non-HTTPS endpoints. For the "ku" endpoint, implementations MUST NOT
follow redirects that change the URI host away from the agent FQDN.
For the "ek" endpoint, implementations MUST NOT follow redirects that
change the URI host away from the domain identified by "gi" or a host
under that domain (Section 5.4). A redirect that violates these
rules MUST cause signature verification to fail unless an applicable
key-discovery profile explicitly defines the delegation and
verification behavior.
12.10. Future Profile Considerations
This base specification deliberately omits mechanisms whose design
space is broader than the minimum interoperable accountability
surface. The following are reserved for future profiles or revisions
and are not specified here:
* Accountable entity record-signing key continuity (e.g., an
ENTITY_KEY_ROTATION event that preserves prior history across an
accountable entity key change).
* Transfer of accountability from one accountable entity to another
while preserving prior public DNSid history.
* Key recovery for the accountable entity record-signing key or the
DNSid operational key following loss or compromise.
* Rotation-consent mechanisms beyond the base previous-operational-
key authorization (for example, an additional accountable-entity
countersignature on rotation, or dual previous-and-new
operational-key countersignatures).
* Verifiable-Credential- or DID-based accountable entity assertions
as an alternative to DNS-native discovery of the accountable
entity record-signing key.
* Role-specific key-age policy (separate maxima for "ek" and "ku"
keys).
Ihsanullah Expires 31 December 2026 [Page 42]
Internet-Draft DNSid June 2026
* High-assurance accountable entity identity requirements (e.g.,
requiring the accountable entity itself to be resolvable as a
DNSid, DID, or legal-registry entry).
* Work-product provenance and content-signature receipt profiles
that bind artifacts to DNSid operational keys and lifecycle
evidence.
Profiles defining any of the above MUST specify their verification
semantics, any lifecycle-event or receipt additions, and
compatibility with this base specification.
13. Privacy Considerations
13.1. Encrypted DNS Transport
Implementations SHOULD use encrypted DNS transport (DoT, [RFC7858] or
DoH, [RFC8484]) when resolving DNSid TXT records. The _dnsid.<fqdn>
query reveals agent-to-agent interaction patterns that may be
privacy-sensitive.
13.2. TLS Handshake Privacy
When a verifier connects to an agent by FQDN, the TLS ClientHello can
reveal that server name to network observers through SNI. Encrypted
Client Hello (ECH) [RFC9849] mitigates this disclosure by encrypting
the inner ClientHello. Implementations that publish HTTPS records
may include ECH configurations.
13.3. Privacy and Pseudonymity
Detailed identity attributes and claims MUST NOT be placed in the TXT
record RDATA. Such attributes, if used, SHOULD be delegated to HTTPS
endpoints or higher-layer mechanisms such as Verifiable Credentials.
URI values in the record SHOULD NOT contain personally identifying
information.
Each DNSid FQDN constitutes a distinct pseudonymous identifier. The
agent operates under its FQDN without exposing the accountable entity
to parties that do not perform an explicit verification. Resolving
the accountable entity behind an agent FQDN may require registrar,
registry, or legal process, depending on how the domain was
registered and operated. Use of distinct registrable domains
provides operational separation of pseudonymous identities. This
property is a deliberate consequence of anchoring identity in the
registrant-domain governance layer rather than in a centralized
directory or certificate authority.
Ihsanullah Expires 31 December 2026 [Page 43]
Internet-Draft DNSid June 2026
13.4. Log Privacy
The accountable entity selects the log technology and determines its
privacy characteristics. When a publicly transparent log is chosen,
lifecycle events (registration, rotation, revocation, retirement) and
any profile-defined optional events can reveal timing patterns.
Operators using public logs SHOULD minimize event payloads and avoid
personally identifying information in log entries.
14. IANA Considerations
This document introduces no new DNS resource record types, opcodes,
or response codes. It requests the following IANA actions:
registration of the underscored node name "_dnsid" in the
"Underscored and Globally Scoped DNS Node Names" registry (see
below), and the creation of three new registries under the "Domain
Name System (DNS) Parameters" group, defined below.
The "_dnsid" underscored node name does not conflict with other
underscore-labeled records published at the same domain, including
"_dmarc", "_domainkey" (DKIM), DANE TLSA records, or other protocol-
or vendor-defined labels. An operator publishing DNSid records MAY
simultaneously publish unrelated underscore-labeled records,
including agent-discovery records that use different owner names,
without interaction at the DNS layer.
The three registries defined below all use the Specification Required
policy ([RFC8126]). For every registration, the designated expert
should confirm that it references a stable, publicly available
specification and that it preserves interoperability with existing
DNSid deployments. For the DNSid TXT Tag Names and DNSid Policy Flag
Names registries, the expert should additionally confirm that a
registration introduces no semantics that would be unsafe for an
existing receiver to ignore. For the DNSid Log Method Registry, the
expert should instead confirm that the binding defines verifier
behavior when the method is unsupported or unrecognized, and includes
security considerations. The expert is not expected to evaluate the
design beyond these interoperability and safety considerations.
14.1. DNSid TXT Tag Names Registry
Registration policy: Specification Required ([RFC8126]).
Registration requests should include the tag name, status, syntax,
semantics, reference, and change controller. New tags registered
under DNSid1 MUST have status OPTIONAL; the REQUIRED status is
reserved for the tags defined by this document or by a future
protocol version, since unknown tags are ignored by existing DNSid1
receivers.
Ihsanullah Expires 31 December 2026 [Page 44]
Internet-Draft DNSid June 2026
+=====+==========+=============================================+
| Tag | Status | Description |
+=====+==========+=============================================+
| v | REQUIRED | Version identifier. MUST be "DNSid1". |
+-----+----------+---------------------------------------------+
| gi | REQUIRED | Governance identifier (accountable entity). |
+-----+----------+---------------------------------------------+
| ek | REQUIRED | Entity key service URI (accountable entity |
| | | record-signing keys). |
+-----+----------+---------------------------------------------+
| ku | REQUIRED | Operational key service URI (DNSid runtime |
| | | signing keys). |
+-----+----------+---------------------------------------------+
| lr | REQUIRED | Log reference. |
+-----+----------+---------------------------------------------+
| su | REQUIRED | Status service URI. |
+-----+----------+---------------------------------------------+
| sg | REQUIRED | Entity signature (base64url) over canonical |
| | | record content; verified via "ek". |
+-----+----------+---------------------------------------------+
| fl | OPTIONAL | Policy flags. |
+-----+----------+---------------------------------------------+
| ka | OPTIONAL | Maximum operational signing key age. |
+-----+----------+---------------------------------------------+
| cu | OPTIONAL | Capabilities URI for AGENTS.md or Agent |
| | | Card material. |
+-----+----------+---------------------------------------------+
Table 5
14.2. DNSid Policy Flag Names Registry
Registration policy: Specification Required ([RFC8126]).
Registration requests should include the flag name, verifier
behavior, reference, and change controller.
+========+===========================================+
| Flag | Description |
+========+===========================================+
| mtls | Verifiers MUST use mutual TLS. |
+--------+-------------------------------------------+
| logchk | Verifiers MUST perform a log-inclusion |
| | check before any operation the deployment |
| | classifies as high-value or irreversible. |
+--------+-------------------------------------------+
Table 6
Ihsanullah Expires 31 December 2026 [Page 45]
Internet-Draft DNSid June 2026
14.3. DNSid Log Method Registry
Registration policy: Specification Required ([RFC8126]).
Registration requests should include the method name, reference
syntax, entry format, proof format, verification procedure, security
considerations, reference, and change controller.
This registry maps DNSid log method names to log binding
specifications. It does not register URI schemes. No initial
entries are defined; log binding specifications register their method
names independently.
This document does not request the registration of a new DNS Resource
Record type. See Appendix C for a non-normative discussion of a
possible future dedicated RR type.
14.4. DNSid Underscore Label Registration
Per [RFC8552], IANA is requested to add the following entry to the
"Underscored and Globally Scoped DNS Node Names" registry:
+=========+============+===============+
| RR Type | _NODE NAME | Reference |
+=========+============+===============+
| TXT | _dnsid | This document |
+---------+------------+---------------+
Table 7
15. References
15.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123,
DOI 10.17487/RFC1123, October 1989,
<https://www.rfc-editor.org/rfc/rfc1123>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
Ihsanullah Expires 31 December 2026 [Page 46]
Internet-Draft DNSid June 2026
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/rfc/rfc4648>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/rfc/rfc5234>.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/rfc/rfc5890>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/rfc/rfc7517>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/rfc/rfc7518>.
[RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK)
Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September
2015, <https://www.rfc-editor.org/rfc/rfc7638>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/rfc/rfc7858>.
[RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH)
and Signatures in JSON Object Signing and Encryption
(JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017,
<https://www.rfc-editor.org/rfc/rfc8037>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
Ihsanullah Expires 31 December 2026 [Page 47]
Internet-Draft DNSid June 2026
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/rfc/rfc8484>.
[RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource
Records through "Underscored" Naming of Attribute Leaves",
BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
<https://www.rfc-editor.org/rfc/rfc8552>.
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/rfc/rfc9525>.
15.2. Informative References
[A2A] Linux Foundation, "Agent2Agent Protocol", n.d.,
<https://a2a-protocol.org/>.
[AGENTS.md]
Community Convention, "AGENTS.md Convention", n.d.,
<https://agents.md/>.
[AGNTCY] Linux Foundation AGNTCY, "Internet of Agents", n.d.,
<https://docs.agntcy.org>.
[I-D.akhavain-moussa-dawn-problem-statement]
Akhavain, A., Moussa, H., and D. King, "Problem Statement
for the Discovery of Agents, Workloads, and Named Entities
(DAWN)", Work in Progress, Internet-Draft, draft-akhavain-
moussa-dawn-problem-statement-04, 12 June 2026,
<https://datatracker.ietf.org/doc/html/draft-akhavain-
moussa-dawn-problem-statement-04>.
[I-D.ietf-dnsop-domain-verification-techniques]
Sahib, S. K., Huque, S., Wouters, P., Nygren, E., and T.
Wicinski, "Domain Control Validation using DNS", Work in
Progress, Internet-Draft, draft-ietf-dnsop-domain-
verification-techniques-13, 21 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
domain-verification-techniques-13>.
Ihsanullah Expires 31 December 2026 [Page 48]
Internet-Draft DNSid June 2026
[I-D.ietf-scitt-architecture]
Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
Y., and S. Lasker, "An Architecture for Trustworthy and
Transparent Digital Supply Chains", October 2025,
<https://datatracker.ietf.org/doc/draft-ietf-scitt-
architecture/>.
[I-D.king-dawn-requirements]
King, D. and A. Farrel, "Requirements for the Discovery of
Agents, Workloads, and Named Entities (DAWN)", Work in
Progress, Internet-Draft, draft-king-dawn-requirements-01,
28 April 2026, <https://datatracker.ietf.org/doc/html/
draft-king-dawn-requirements-01>.
[I-D.mozleywilliams-dnsop-dnsaid]
Mozley, J., Williams, N., Sarikaya, B., Schott, R., and J.
Damick, "DNS for AI Discovery", Work in Progress,
Internet-Draft, draft-mozleywilliams-dnsop-dnsaid-02, 27
May 2026, <https://datatracker.ietf.org/doc/html/draft-
mozleywilliams-dnsop-dnsaid-02>.
[I-D.noss-jeftovic-groundmark-attestation]
noss, E. and M. E. Jeftovic, "Groundmark Attestation
Framework and Identity Service Provider Profile", Work in
Progress, Internet-Draft, draft-noss-jeftovic-groundmark-
attestation-00, 24 May 2026,
<https://datatracker.ietf.org/doc/html/draft-noss-
jeftovic-groundmark-attestation-00>.
[I-D.noss-jeftovic-groundmark-core]
noss, E. and M. E. Jeftovic, "DNS-Anchored Identity
Discovery for Autonomous Agents", Work in Progress,
Internet-Draft, draft-noss-jeftovic-groundmark-core-00, 24
May 2026, <https://datatracker.ietf.org/doc/html/draft-
noss-jeftovic-groundmark-core-00>.
[MCP] Anthropic, "Model Context Protocol", n.d.,
<https://modelcontextprotocol.io>.
[NGAC] NIST, "Next Generation Access Control", n.d.,
<https://csrc.nist.gov/projects/access-control-policy-and-
implementation-guides/next-generation-access-control>.
[NIST-IR-8547]
NIST, "Transition to Post-Quantum Cryptography Standards",
November 2024, <https://csrc.nist.gov/pubs/ir/8547/ipd>.
Ihsanullah Expires 31 December 2026 [Page 49]
Internet-Draft DNSid June 2026
[NIST-PQC] NIST, "Post-Quantum Cryptography Standards: FIPS 203, 204,
205", August 2024, <https://csrc.nist.gov/news/2024/
postquantum-cryptography-fips-approved>.
[OAuth2.1] Hardt, D., Parecki, A., and T. Lodderstedt, "The OAuth 2.1
Authorization Framework", February 2025,
<https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/>.
[OIDC] OpenID Foundation, "OpenID Connect Core 1.0", November
2014,
<https://openid.net/specs/openid-connect-core-1_0.html>.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
<https://www.rfc-editor.org/rfc/rfc2308>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/rfc/rfc6376>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/rfc/rfc6698>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/rfc/rfc6763>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<https://www.rfc-editor.org/rfc/rfc6962>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/rfc/rfc7208>.
[RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.
[RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
and Parameter Specification via the DNS (SVCB and HTTPS
Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.
Ihsanullah Expires 31 December 2026 [Page 50]
Internet-Draft DNSid June 2026
[RFC9849] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", RFC 9849, DOI 10.17487/RFC9849,
March 2026, <https://www.rfc-editor.org/rfc/rfc9849>.
[RFC9989] Herr, T., Ed. and J. Levine, Ed., "Domain-Based Message
Authentication, Reporting, and Conformance (DMARC)",
RFC 9989, DOI 10.17487/RFC9989, May 2026,
<https://www.rfc-editor.org/rfc/rfc9989>.
[SCIM] Hunt, P., Grizzle, K., Ansari, M., Wahlstroem, E., and C.
Mortimore, "System for Cross-domain Identity Management:
Protocol", September 2015,
<https://datatracker.ietf.org/doc/html/rfc7644>.
[SPIFFE] SPIFFE Project, "The SPIFFE Identity and Verifiable
Identity Document", n.d., <https://spiffe.io>.
Appendix A. Relationship to Adjacent Standards
This appendix provides informative context on how DNSid relates to
adjacent efforts in the agent identity ecosystem.
A recurring distinction applies across these efforts: discovery and
connectivity standards answer where an agent is and how to reach it,
while DNSid answers which accountable entity owns an agent and over
what history. These are complementary layers, not competing
alternatives. DNSid is intended to be referenced by the efforts
below rather than to replace them.
SPIFFE/SPIRE: SPIFFE [SPIFFE] provides strong runtime workload
identity at Layer 3. Its specification acknowledges that trust
domain names are "nominally self-registered" with no delegating
authority. DNSid provides the governance-backed ownership that
SPIFFE trust domains can reference but do not define. SPIFFE
SVIDs can include the DNSid FQDN as a URI SAN.
GoDaddy ANS: GoDaddy's Agent Name Service uses DNS-anchored FQDNs
with ACME domain control validation and a Merkle-tree transparency
log. ANS spans multiple layers (L1, L2, L7). DNSid focuses
solely on the Layer 1 ownership anchor and is designed to compose
with ANS or operate independently.
Web Bot Auth: Built on HTTP Message Signatures [RFC9421] for
Ihsanullah Expires 31 December 2026 [Page 51]
Internet-Draft DNSid June 2026
automated traffic (draft-meunier-web-bot-auth-architecture).
Provides per-request cryptographic authentication at Layer 4. The
signing key directory at /.well-known/http-message-signatures-
directory may share the JWKS endpoint referenced by DNSid's "ku"
tag only where the constraints in Section 7.1 hold (exactly one
JWK usable for the DNSid operation, no verifier selection);
otherwise a dedicated DNSid endpoint is used.
A2A AgentCard: The Agent2Agent Protocol's AgentCard is a JSON
metadata document at /.well-known/agent-card.json that describes
agent capabilities, endpoints, and skills at Layer 7. DNSid's
optional "cu" tag can reference an AgentCard. The AgentCard's
provider claim can reference the DNSid governance anchor domain,
enabling verifiers to confirm the provider claim through DNSid
verification.
IETF WIMSE/AIMS: WIMSE extends workload identity tokens with agent-
specific claims. The AIMS framework composes WIMSE, SPIFFE,
OAuth, and Transaction Tokens. Both operate at Layers 3-4. DNSid
provides the Layer 1 anchor that WIMSE tokens can reference for
organizational accountability.
AGENTS.md: A markdown file convention declaring agent capabilities
and policies. DNSid's capabilities pointer (the "cu" tag) can
reference an AGENTS.md document, providing the identity anchor
that AGENTS.md declares capabilities for.
DNS-AID: DNS-AID [I-D.mozleywilliams-dnsop-dnsaid] ("DNS for AI
Discovery", an individual draft) uses SVCB [RFC9460] records and
DNS-SD, with optional DNSSEC/DANE hardening, to publish where an
organization's agents are and how to reach them. It introduces no
new DNS record types and provides a verifiable transport for
discovery metadata, not a durable ownership record. DNSid is
complementary: a verifier that discovers an agent via DNS-AID can
resolve the corresponding "_dnsid" owner name for the agent FQDN
to establish which accountable entity owns that agent over time.
The two use different owner names and do not conflict.
Groundmark: Groundmark [I-D.noss-jeftovic-groundmark-core] publishes
Ihsanullah Expires 31 December 2026 [Page 52]
Internet-Draft DNSid June 2026
DNSSEC-protected "_agentid" TXT records carrying agent request-
signing keys and "_agentclaim" records pointing to externally
hosted Identity Service Provider attestations
[I-D.noss-jeftovic-groundmark-attestation]. Groundmark focuses on
request authentication (HTTP Message Signatures, [RFC9421]),
operator-accountability discovery, and attestation, and requires
DNSSEC. DNSid focuses on durable ownership anchoring, lifecycle
history, status, and key continuity. The two use different
underscored labels and MAY coexist at the same agent FQDN; they
address different accountability surfaces (current operator
attestation versus durable owner binding).
DAWN: The DAWN problem statement and requirements
[I-D.akhavain-moussa-dawn-problem-statement]
[I-D.king-dawn-requirements] address discovery of agents,
workloads, and named entities. They treat entity registration,
naming-system governance, and entity authentication as separate
upstream concerns. DNSid is an example of a DNS-based
accountability anchor that discovery mechanisms can reference when
they need durable ownership and lifecycle evidence.
DNS-SD: DNS-Based Service Discovery [RFC6763] extends DNS to locate
services. DNS-SD discovers what services exist; DNSid establishes
who is accountable for them. The two are complementary and
operate at different layers.
W3C DIDs and Verifiable Credentials: DIDs and VCs operate at the
cryptographic identity and claims layers above DNSid. A DNSid
FQDN MAY be the subject of a Verifiable Credential. A DID such as
did:web MAY be associated with a DNSid FQDN through a VC or log
event. DNSid does not define a DID method, does not issue or
revoke Verifiable Credentials, and does not infer accountability
from DID resolution alone.
SCITT: IETF SCITT [I-D.ietf-scitt-architecture] defines append-only
transparency services. A SCITT-compatible service is one
candidate implementation for DNSid's abstract log interface.
Appendix B. Ecosystem Relationship Map
The following table summarizes how DNSid relates to adjacent efforts
in the agent identity ecosystem:
Ihsanullah Expires 31 December 2026 [Page 53]
Internet-Draft DNSid June 2026
+=====================+=======+====================================+
| Project | Layer | DNSid Relationship |
+=====================+=======+====================================+
| ICANN/DNSSEC | 0 | DNSid builds on Layer 0 |
+---------------------+-------+------------------------------------+
| DANE (RFC 6698) | 0, 2 | Optional hardening for key binding |
+---------------------+-------+------------------------------------+
| GoDaddy ANS | 1,2,7 | Complementary; ANS spans more |
| | | layers |
+---------------------+-------+------------------------------------+
| Web Bot Auth | 4 | Per-request auth complement; JWKS |
| | | sharing constrained |
+---------------------+-------+------------------------------------+
| SPIFFE/SPIRE | 3 | SVID can reference DNSid FQDN |
+---------------------+-------+------------------------------------+
| OAuth 2.1/OIDC | 4 | Tokens can include DNSid org ID |
+---------------------+-------+------------------------------------+
| NGAC/OPA/Cedar | 5 | Policies reference DNSid ownership |
+---------------------+-------+------------------------------------+
| SCIM for Agents | 6 | Provisioning may trigger DNSid |
| | | events |
+---------------------+-------+------------------------------------+
| A2A AgentCard | 7 | Provider claim references DNSid |
| | | anchor |
+---------------------+-------+------------------------------------+
| MCP/AGNTCY | 7 | AGENTS.md referenced via "cu" tag |
+---------------------+-------+------------------------------------+
| AGENTS.md | 7 | Capabilities doc; DNSid is |
| | | identity |
+---------------------+-------+------------------------------------+
| WIMSE/AIMS | 3-4 | WIMSE tokens reference DNSid FQDN |
+---------------------+-------+------------------------------------+
| W3C DIDs/VCs | 2 | VCs can attest DNSid ownership |
+---------------------+-------+------------------------------------+
| RFC 9421 (HTTP | 4 | Complementary request signatures; |
| Message Signatures) | | key reuse profile-constrained |
+---------------------+-------+------------------------------------+
| SCITT | 2 | Log architecture aligned |
+---------------------+-------+------------------------------------+
| DNS-AID | 7 | Discovers agents (SVCB); DNSid |
| | | anchors ownership |
+---------------------+-------+------------------------------------+
| Groundmark | 1/4 | Operator attestation; DNSid |
| | | anchors durable owner |
+---------------------+-------+------------------------------------+
| DNS-SD (RFC 6763) | 7 | Discovers services; DNSid anchors |
| | | accountability |
+---------------------+-------+------------------------------------+
Ihsanullah Expires 31 December 2026 [Page 54]
Internet-Draft DNSid June 2026
Table 8
DNSid is designed to be a small, focused Layer 1 primitive that all
of these systems can reference independently.
Appendix C. Migration Path to Dedicated RR Type
This appendix is non-normative. The TXT record encoding defined in
this specification is the normative DNSid1 wire format. It is
designed to deploy on existing DNS infrastructure without a new
resource record type, while using an underscore-scoped owner name, a
singleton RRset rule, a first-position version tag, and a compact
pointer format to minimize ambiguity. This follows established DNS-
anchored application-identity practice (SPF, DKIM, DMARC). No
dedicated RR type is requested by this document. Should the
community later determine that type-specific wire encoding is
warranted, a future specification may define a dedicated DNSID RR
type or a multi-version transition mechanism; that work would need to
specify its own preference and fallback behavior, record selection,
field consistency across encodings or versions, and signature-
verification rules. Such a change would affect the wire format only,
not the trust architecture, verification protocol, or HTTP/log
integration.
Appendix D. Acknowledgments
This work builds on the DNSid concept developed at Identity Digital
Innovation Labs. The author thanks Ben Guidarelli for contributions
to the TXT record encoding profile, Jason Weathersby for technical
review, Emily Edwards for product refinement, and the participants of
the Linux Foundation AAIF Identity and Trust Working Group for
ongoing discussion.
The TXT record encoding follows conventions established by DKIM
([RFC6376]), DMARC ([RFC9989]), and SPF ([RFC7208]).
Author's Address
Naveed Ihsanullah
Identity Digital
Email: naveed.ihsanullah@identity.digital
Ihsanullah Expires 31 December 2026 [Page 55]