The DNSid IETF draft

DNSid is proposed in an individual IETF Internet-Draft. The reference implementation follows the draft’s core TXT-record and verification model, while documenting implementation deltas as the specification evolves.

The IETF draft

The current revision is draft-ihsanullah-dnsid-01. It is an individual submission, not an IETF-endorsed standard or a working-group document. The -01 draft was submitted on June 29, 2026 and expires on December 31, 2026; the original -00 was submitted April 30, 2026. Track the current draft and revision history on the IETF Datatracker.

The draft defines DNSid as a DNS-anchored durable identity primitive for AI agents: each agent has its own FQDN bound to an accountable entity’s domain, a signed _dnsid TXT record, pointers to cryptographic keys, lifecycle status, and lifecycle history. The lifecycle log is deliberately log-technology-neutral: the draft specifies required properties (append-only, provable inclusion, verifiable timestamps) and delegates concrete bindings—the C2SP transparency log today, blockchains or other immutable stores tomorrow—to per-method specifications in a registry, analogous to W3C DID methods.

Standard vs. reference implementation

Note

The draft describes the record format, signature scheme, and verification semantics. The open-source SDKs implement the current profile, and anyone can build an independent implementation from the draft.

Wire-level implementers should verify behavior against the SDK profile, including the exact v=dnsid-draft-01 record selector and algorithm-prefixed sg= signatures. The SDKs also accept pre-RFC v=DNSid1 records for verification.

Building a compliant implementation

A compliant implementation needs to produce and verify the same wire surfaces the reference SDK uses today: the _dnsid TXT record, the algorithm-prefixed record signature embedded in that record, the agent JWKS, and the status document.

• _dnsid TXT record—publish one TXT record below the agent FQDN with version, key URI, status URI, lifecycle-log reference, governance identifier, optional policy flags, and an algorithm-prefixed signature field.
• Record signature—verify sg= against the eligible signing key from the JWKS at the signed key URI. Current records are signed by the accountable entity’s key.
• Agent JWKS—expose the active agent signing key at the signed key URI.
• Status document—expose lifecycle state at the signed status URI so verifiers can reject revoked or inactive agents.

Next steps

Give an agent an identityTXT records, JWKS, and status URLs.

SDK overviewThe open-source SDKs that implement the draft.