Robots Atlas>ROBOTS ATLAS

DNSid

2026ExperimentalPublished: 30 April 2026Updated: 16 July 2026Published
Key innovation
Using the globally delegated DNS namespace as a durable identity anchor for AI agents, binding each agent to an accountable entity through an FQDN and a structured TXT record (`_dnsid.<agent-fqdn>`) โ€” with an entity signature that takes precedence over DNSSEC.
Category
Abstraction level
Pattern
Operation level
Agent runtimeSystemApplicationDeployment
Use cases
Enterprise AI agent deployments โ€” binding each agent to an accountable organisation for audit, compliance, and post-incident forensicsCross-organisational agent-to-agent transactions โ€” verifying the identity of a foreign agent before signing a contract or transactionProvenance of agent-generated work products (code, reports, decisions) โ€” content signing recorded in the ledger, verifiable years laterRevocation propagation โ€” when an agent is compromised, updating the status endpoint and the REVOCATION ledger entry automatically invalidates it for all verifiersDelegation chains โ€” tracking which agent delegated authority to which, for what scope, and until whenAI Bill of Materials โ€” linking agents, their models, training data, and providers for governance audits

How it works

1) The accountable entity registers the agent FQDN (e.g. `billing-agent-acme.example`). 2) It publishes a TXT record at `_dnsid.<fqdn>` with tags: v=DNSid1, oi (governance identifier), ku (JWKS URI), lr (ledger reference), su (status URI), sg (record signature). 3) The agent has a JWKS endpoint at `.well-known/jwks.json` with current keys. 4) An immutable ledger (blockchain, CT-log, SCITT) records all lifecycle events (ISSUANCE, KEY_ROTATION, REVOCATION, RETIREMENT, MIGRATION, optional DELEGATION and CONTENT_SIG), signed by the accountable entity's key. 5) A verifier resolves `_dnsid.<fqdn>`, fetches the JWKS, verifies the record signature, checks the status endpoint, and establishes HTTPS/mTLS with the agent FQDN. For high-trust operations: additionally queries the ledger for the ISSUANCE event and the absence of a REVOCATION.

Problem solved

No existing identity standard (OAuth 2.1, OIDC, SPIFFE/SPIRE, SCIM, NGAC, MCP) answers the question: who is accountable for this AI agent, and can any system verify that independently. Autonomously operating AI agents negotiate, transact, delegate, and produce artifacts that persist beyond their runtime. This requires a durable, governance-backed ownership anchor โ€” something the existing IAM stack does not provide.

Components

DNSid TXT RecordA structured DNS TXT record at `_dnsid.<agent-fqdn>` with identity tags (v, oi, ku, lr, su, sg + optional fl/ka/cu). A pointer entry to HTTPS endpoints and the ledger.
Agent FQDNThe agent's globally unique Fully Qualified Domain Name (e.g. billing-agent-acme.example) โ€” the primary identifier carried in protocol messages, max 246 octets.
JWKS Key EndpointAn HTTPS service in RFC 7517 format returning the agent's active signing keys with `kid` and `alg` metadata. Convention: `https://<fqdn>/.well-known/jwks.json`.
Status EndpointAn HTTPS service returning the agent's current state (PENDING/PROVISIONING/VERIFYING/ACTIVE/RETIRED/REVOKED), the last-transition timestamp, and a reason code for REVOKED.
Immutable LedgerAn append-only verifiable log of lifecycle events (ISSUANCE, KEY_ROTATION, REVOCATION, RETIREMENT, MIGRATION + optional DELEGATION, CONTENT_SIG). Ledger-neutral: blockchain, Merkle tree, CT log, SCITT.
Entity Signature (sg tag)A base64url signature of the entire TXT record (excluding the sg tag itself) by the accountable entity's key. Algorithms: ES256 (MUST), Ed25519 (SHOULD), ML-DSA (post-quantum, SHOULD).

Implementation

Implementation pitfalls
Critical
Fix:Always require and verify the `sg` tag โ€” an accountable-entity-controlled signature is an architectural requirement of DNSid, not an option.
High
Fix:The DNSid TXT record TTL should be short (300โ€“3,600 s). The verifier MUST also query the status endpoint for interactive operations.
Medium
Fix:Use deployment managed by a single DNS management tool; monitor for duplicates.
High
Fix:Prefer publicly queryable ledgers (blockchain, CT log). For private ones โ€” require durability SLAs and export procedures.
Medium
Fix:Use DNSid as a foundation for OAuth/OIDC/SPIFFE โ€” for runtime authentication, not as their replacement.

Hyperparameters (configurable axes)

Ledger technologyCritical

Choice of ledger implementation: blockchain (Algorand, Ethereum), a Merkle-tree CT-style log, a SCITT transparency service, or a private append-only log. DNSid is ledger-neutral.

Signing algorithmHigh

ES256 (MUST, ECDSA P-256), Ed25519 (SHOULD), ML-DSA (post-quantum, SHOULD after registration with JWS). Expressed in the JWK's `alg` field.

Key age limit (ka tag)Medium

24h / 7d / 30d / 90d / unbounded. Trade-off between security (more frequent rotation) and operational overhead.

Policy flags (fl tag)Medium

mtls (require mutual TLS), logchk (require a ledger inclusion check before a high-value operation). An extensible vocabulary.

Domain deployment modeHigh

Dedicated registrable domain per agent (maximum pseudonymity + governance separation) vs shared organisational subdomain (operational simplicity + shared accountability scope).

DNSSEC deploymentHigh

No DNSSEC (verifier relies on sg alone โ€” reduced assurance) vs DNSSEC (strongest โ€” DNS transport integrity + entity signature).

Execution paradigm

Primary mode
Conditional

Verification is conditional โ€” flags (`fl=logchk,mtls`) and `ka=<age>` determine the extent of checks (record itself, JWKS, status, ledger). Many expensive steps (ledger lookup) only run for high-trust operations.

Activation pattern
Input dependent

Parallelism

Parallelism level
Fully parallel

DNSid verification is fully parallelisable โ€” each verifier can independently resolve DNS, fetch JWKS, verify signatures, and query the ledger, with no shared state.

Scope
InferenceAcross devices

Hardware requirements

Primary