DNS-Anchored Durable Identity for AI Agents (DNSid)

DNS-Anchored Durable Identity for AI Agents (DNSid) Identity Digital

naveed.ihsanullah@identity.digital

Operations and Management Individual Submission DNS agent identity AI agents ownership governance TXT record 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.

Introduction and Motivation

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 , OIDC , SPIFFE/SPIRE , SCIM , NGAC , and 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. 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.

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.

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 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 and DMARC 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 .
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 ).
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 , DIDs, VCs, and 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 and may be an inexpensive or opaque name. The accountability chain therefore terminates at the "gi" registrant rather than in agent-to-agent recursion.

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 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 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 ). 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 still apply, while record-integrity-only and offline historical processing follow their own requirements.
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).

Ecosystem Context and Scope

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 Ownership Anchor	DNSid operates here
2	Cryptographic Identity Binding	DIDs, VCs, PKI
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 Interoperability	MCP, A2A, AGNTCY

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.

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

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:

Claim	Question	DNSid Mechanism
Record integrity	Was this TXT record signed by the accountable entity?	Entity signature ("sg" tag) verified against JWKS over HTTPS
DNS authenticity	Was the DNS response tampered with in transit?	DNSSEC, when deployed; absent = reduced assurance
Real-world legitimacy	Is the accountable entity trustworthy or reputable?	Out of scope; determined by relying-party policy, external registries, or Verifiable Credentials

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.

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

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

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. 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 ). 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 style log, or similar verifiable data structure. The architectural requirement is append-only integrity with cryptographic inclusion proofs, not a specific implementation. See for the abstract log interface.

The DNSid TXT Record

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: ]]> Example: The underscore prefix follows the underscore scoping model of 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 ( Section 2.3.4, Section 2.1). The TTL of DNSid TXT records SHOULD be kept short enough to support timely revocation propagation.

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 (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 () and DMARC (). 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 . Formal syntax (ABNF, ): Tag names are case-sensitive. Unknown tags MUST be ignored by receivers to provide forward-compatibility for future extensions. 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 (). 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 . DNSid1 therefore defines no overlapping-version behavior; discusses what a future transition, including migration to a dedicated RR type, would need to specify.

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 (). 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 ().
lr	REQUIRED	Log reference. Structured reference identifying the log binding and the agent's entry.
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.

Implementations MUST reject a DNSid TXT record that is missing any REQUIRED tag or in which a REQUIRED tag has an empty value.

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 (). 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: 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
for a delegated DNSid whose agent FQDN is not under the "gi" domain, the bilateral ISSUANCE event (see and ) 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 () 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".

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 (). Examples (method names are illustrative):

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:

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.

Example: fl=mtls,logchk The "logchk" flag governs the policy-gated log-inclusion check (); it is distinct from, and does not replace, the mandatory bilateral ISSUANCE binding check ( step 5). This specification does not classify which operations are high-value or irreversible; that classification is a deployment or relying-party policy matter.

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.

Multi-String Encoding DNS TXT RDATA is represented as one or more character-strings, each limited to 255 octets ( 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): " ) ]]> 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: " ) ]]> 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 and ).

Entity-Signed Record Integrity

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

Signature Generation The "sg" tag contains a signature computed as follows:

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.
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".
Encode the signature as base64url ( 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) ; the ES256 signature is the fixed-width R||S form defined by JWA ( Section 3.4), not an ASN.1 DER encoding. Implementations SHOULD support Ed25519, whose signatures use the JOSE/OKP representation defined for EdDSA in . When post-quantum algorithms are registered for use with JWS, implementations SHOULD add support for ML-DSA (FIPS 204) .

Signature Verification A verifier:

Fetches the JWKS from the "ek" endpoint over HTTPS.
Reconstructs the canonical record string (all tags except "sg", alphabetical order, no whitespace).
Verifies the "sg" value against the canonical string using the public key from the "ek" JWKS.
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 ) and does not establish that the DNSid operational identity consented to the accountable entity (see and the ISSUANCE event in ). The live "ek" JWKS contains exactly one current record-signing key (see ); 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 ), 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 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.

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 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 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 ( 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 () for the key service (see ). 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.

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.

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 ). 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 (). The endpoint MUST return a JWK Set () 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, ) 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. 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 ), 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 () TLSA records (certificate usage 3, DANE-EE) for cryptographic binding between the FQDN and the TLS certificate, eliminating dependence on external certificate authorities.

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 () over HTTPS. The response:

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, ) that matches the "ek" URI host. The "ek" URI host MUST be the domain identified by "gi" or a host under that domain; see 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 ), not the live endpoint. The algorithm for "sg" generation is declared by the "alg" field of the JWK at the "ek" endpoint.

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 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, ) 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 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.

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 ). DNSid does not require the agent or its identity endpoints to be publicly reachable or discoverable.

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.

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 (). 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 (), 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.

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.
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 ); 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 (). It does NOT define a universal encoding, canonicalization, inclusion-proof format, or byte-level layout for lifecycle events. Each registered log method () 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.

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 ), 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 ). The log method records and witnesses the event's inclusion. All other lifecycle events MUST carry the accountable entity signature. 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 ), 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 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).

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 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 ). 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 ).
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 constraints, expiry. Recorded when one agent grants authority to another.

Additional event types MAY be defined in companion specifications.

Verification Protocol DNSid verification combines DNS resolution, accountable entity signature validation, TLS-based live identity, and optional log queries.

Interactive Verification

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.
The verifier validates that "v=DNSid1" is the first tag and that all REQUIRED tags are present and non-empty.
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 (). 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.
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 . DNSid does not define the application protocol or runtime authentication exchange.
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:
- 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 ), 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 ; 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.

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.

Lifecycle Events

Agent States An agent identity progresses through a linear state machine. Each transition is a log event. PROVISIONING --> VERIFYING --> ACTIVE | [key rotation] [delegation] / \ / \ RETIRED REVOKED (graceful end) (forced end + reason) ]]>

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.

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

Key Rotation Procedure KEY_ROTATION rotates the DNSid operational key (the key discovered via "ku"). Routine operational-key rotation proceeds as follows:

The agent generates a new operational key pair.
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 ).
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.
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.

The KEY_ROTATION event MUST be signed by the previous operational key over the new key, as specified in ; 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 (). 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.

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.

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 ); 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.

Security Considerations

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 (). 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-accountable-entity binding additionally perform the bilateral binding check on the ISSUANCE event ( step 5), which does not depend on DNSSEC state. DNSid's entity signature is related to, but distinct from, domain control validation (): 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.

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 ), 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 ), not by key reuse. 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.

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.

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.

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 () 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 ) modest for names intended to carry DNSid records.

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 ( and ) 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 . 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.

Log Durability Organizations SHOULD choose log technologies with strong durability guarantees and broad operational support. The MIGRATION event type () 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 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.

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 (see ), and reissuing the agent without the old key produces a new identity by local policy, not continuity-preserving DNSid history.

URI Integrity The HTTPS endpoints referenced by "ek", "ku", "su", and "cu" tags depend on TLS for integrity. All URI values in DNSid tags MUST conform to . 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 (). 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.

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

Privacy Considerations

Encrypted DNS Transport Implementations SHOULD use encrypted DNS transport (DoT, or DoH, ) when resolving DNSid TXT records. The _dnsid.<fqdn> query reveals agent-to-agent interaction patterns that may be privacy-sensitive.

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) mitigates this disclosure by encrypting the inner ClientHello. Implementations that publish HTTPS records may include ECH configurations.

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.

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.

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

DNSid TXT Tag Names Registry Registration policy: Specification Required (). 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.

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.

DNSid Policy Flag Names Registry Registration policy: Specification Required (). 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.

DNSid Log Method Registry Registration policy: Specification Required (). 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 for a non-normative discussion of a possible future dedicated RR type.

DNSid Underscore Label Registration Per , 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

References Normative References Domain names - implementation and specification This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. Requirements for Internet Hosts - Application and Support This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK] Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The Base16, Base32, and Base64 Data Encodings This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] Augmented BNF for Syntax Specifications: ABNF Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK] JSON Web Key (JWK) A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. JSON Web Algorithms (JWA) This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. JSON Web Key (JWK) Thumbprint This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint. Specification for DNS over Transport Layer Security (TLS) This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE) This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE). Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. DNS Queries over HTTPS (DoH) This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. Uniform Resource Identifier (URI): Generic Syntax A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] The Transport Layer Security (TLS) Protocol Version 1.3 This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. Service Identity in TLS Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions. This document obsoletes RFC 6125. Informative References Negative Caching of DNS Queries (DNS NCACHE) RFC1034 provided a description of how to cache negative responses. It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching. This document addresses issues raise in the light of experience and replaces RFC1034 Section 4.3.4. [STANDARDS-TRACK] DomainKeys Identified Mail (DKIM) Signatures DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK] DNS-Based Service Discovery This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD. Certificate Transparency This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization. This document obsoletes RFC 4408. HTTP Message Signatures This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records) This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. TLS Encrypted Client Hello This document describes a mechanism in Transport Layer Security (TLS) for encrypting a message under a server public key. Domain-Based Message Authentication, Reporting, and Conformance (DMARC) This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol. DMARC permits the owner of an email's Author Domain to enable validation of the domain's use to indicate the Domain Owner's or Public Suffix Operator's message handling preference regarding failed validation and to request reports about the use of the domain name. Mail-receiving organizations can use this information when evaluating handling choices for incoming mail. This document obsoletes RFCs 7489 and 9091. Domain Control Validation using DNS Brave Software Salesforce Aiven Akamai Technologies Cox Communications Many application services on the Internet need to verify ownership or control of a domain in the Domain Name System (DNS). The general term for this process is "Domain Control Validation", and it can be done using a variety of methods such as email, HTTP/HTTPS, or the DNS itself. This document focuses only on DNS-based methods, which typically involve the Application Service Provider requesting a DNS record with a specific format and content to be visible in the domain to be verified. There is wide variation in the details of these methods today. This document provides some best practices to avoid known problems. DNS for AI Discovery Infoblox, Inc. Infoblox, Inc. Unaffiliated Deutsche Telekom Amazon The document standardizes an approach for publishing AI agents in the Domain Name System (DNS) so that other agents can discover them. Discovery is then initiated based on one of three generic use cases, in increasing computational and latency cost: (1) the requestor knows both the organization and agent (2) the requestor knows the organization that provides a capability, but not the specific agent (3) the requestor knows the required capability, but not the organization or agent. Of these use cases only (1) and (2) are in scope for this document, although (3) can be derived from this specification. DNS for AI Discovery (DNS-AID) is designed so that, once a client has learned an organization's agents, subsequent transactions can utilize the first use case with the benefit of cacheable connectivity information that is learnable as an agentic skill. The mechanism uses Service Binding (SVCB) records for connectivity information and key meta data, a well known entry point using DNS-Based Service Discovery (DNS-SD) labels into an organization's agent index, and optionally DNS Security Extensions (DNSSEC) and DNS-Based Authentication of Named Entities (DANE) TLSA records for trust and security. DNS-AID provides consumers of agent services with a direct connection method for agentic workloads not mediated by a third party. Organizations can use the same approach across public and private networks networks, providing consistency and common operational models, including publishing agents that are hosted in service provider domains. This document introduces no new resource record types, opcodes, or response codes. Requirements for the Discovery of Agents, Workloads, and Named Entities (DAWN) Old Dog Consulting Old Dog Consulting The proliferation of distributed systems, Artificial Intelligence (AI) agents, cloud workloads, and network services has created a need for interoperable mechanisms to discover entities across administrative and network boundaries. Entities may include AI agents, software services, compute workloads, and other named resources that need to be found and characterised before interaction can begin. This document defines the requirements for Discovery of Agents, Workloads, and Named Entities (DAWN) and sets out the objectives that a discovery mechanism for such entities must satisfy. It describes what information must be discoverable, what properties a discovery mechanism needs to support, and what constraints apply to discovery in decentralised environments. This document does not specify any particular discovery protocol or solution. Problem Statement for the Discovery of Agents, Workloads, and Named Entities (DAWN) Huawei Technologies Canada Huawei Technologies Canada Old Dog Consulting Interacting entities such as agents, tasks, users, workloads, data, compute, etc., in AI ecosystem/network are proliferating, yet there is no standardised way to discover what entities exist, what attributes such as skills, capabilities, physical characteristics, etc., they posses, what services they offer, or how to reach them across organisational boundaries. Discovery today relies on proprietary directories or manual configuration, creating fragmented ecosystems that prevent cross- domain collaboration. This document describes the problem space that motivates Discovery of Agents, Workloads, and Named Entities (DAWN). It clarifies the scope of work within entity ecosystems, identifies why current approaches are insufficient, and outlines the challenges a standardised discovery mechanism must address. It does not propose a specific solution or protocol. DNS-Anchored Identity Discovery for Autonomous Agents Groundmark easyDNS Technologies Inc. This document defines the core of Groundmark, a protocol for DNS- anchored identity discovery and request authentication for autonomous software agents. Operators publish an agent's signing public key in a DNS TXT record under a reserved label, and optionally publish references to externally hosted attestations under a second reserved label. Agents authenticate HTTP requests using HTTP Message Signatures (RFC 9421) with a key identifier that resolves through DNS. DNSSEC is required for all Groundmark DNS lookups. The protocol provides operator accountability discovery without a central registry, and is designed to compose with existing identity, authorization, and payment systems rather than to replace them. The attestation framework, including the role of Identity Service Providers, the attestation level taxonomy, and the claim vocabulary, is defined in a companion document. Groundmark Attestation Framework and Identity Service Provider Profile Groundmark easyDNS Technologies Inc. This document defines the Groundmark attestation framework and the profile of Identity Service Providers (IDSPs) that issue Groundmark attestations. It is the companion document to the Groundmark core protocol, which specifies DNS publication and request-signature mechanics. This document specifies the role and obligations of Identity Service Providers, a four-level taxonomy of attestation strength, an initial vocabulary of claim types, the JSON schema and signature construction for attestation payloads, the method- disclosure discipline that defines an IDSP's accountability obligation, and revocation semantics for the attestation layer. The core protocol document defines the discovery mechanisms (the _agentclaim DNS TXT record and the HTTP retrieval of attestation payloads) on which this document depends. Together the two documents specify Groundmark. An Architecture for Trustworthy and Transparent Digital Supply Chains The SPIFFE Identity and Verifiable Identity Document SPIFFE Project n.d. Post-Quantum Cryptography Standards: FIPS 203, 204, 205 NIST Transition to Post-Quantum Cryptography Standards NIST The OAuth 2.1 Authorization Framework OpenID Connect Core 1.0 OpenID Foundation System for Cross-domain Identity Management: Protocol Next Generation Access Control NIST n.d. Model Context Protocol Anthropic n.d. Agent2Agent Protocol Linux Foundation n.d. Internet of Agents Linux Foundation AGNTCY n.d. AGENTS.md Convention Community Convention n.d.

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 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 for 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 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 ("DNS for AI Discovery", an individual draft) uses SVCB 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 publishes DNSSEC-protected "_agentid" TXT records carrying agent request-signing keys and "_agentclaim" records pointing to externally hosted Identity Service Provider attestations . Groundmark focuses on request authentication (HTTP Message Signatures, ), 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 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 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 defines append-only transparency services. A SCITT-compatible service is one candidate implementation for DNSid's abstract log interface.

Ecosystem Relationship Map The following table summarizes how DNSid relates to adjacent efforts in the agent identity ecosystem:

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 Message Signatures)	4	Complementary request 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

DNSid is designed to be a small, focused Layer 1 primitive that all of these systems can reference independently.

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.

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 (), DMARC (), and SPF ().