Publish self-managed records

A self-managed identity is the pure-protocol path: you own the domain, you sign the record with your entity key, and you host the endpoints the record points to. Verifiers with trust configured for your lifecycle log can check the result through the same DNS, HTTPS, and log flow as any other DNSid identity.

What you operate

To publish a self-managed identity for agent.example you need:

• The DNS zone—you publish one TXT record at _dnsid.agent.example.
• Two JWKS endpoints—the record’s ek= URL serves the accountable entity’s public record-signing key under the governance domain; ku= serves the agent’s public operational key under the agent’s domain. Both URLs must be set explicitly.
• A status endpoint—the record’s su= URL, serving the agent’s live lifecycle state. You control its freshness; see the guidance in Status & freshness.
• A lifecycle log—the record’s lr= reference. The transparency log guide covers the C2SP tlog binding and what verifiers check against it.
• Your keys—distinct entity and operational keys, each managed through a key provider. Pass the entity key provider as a dependency when constructing the manager to sign records.

Build and sign the record

Set the ek and ku URLs in the identity config and supply both key providers. Then call CreateTXTRecord() in Go, createTxtRecord() in TypeScript, or create_txt_record() in Python. Go returns a record you can serialize with Serialize(); TypeScript and Python return the TXT value directly. Publish the value with your normal DNS tooling.

The per-language record APIs are in the reference: Go records & keys · TypeScript · Python records & keys.

If you use the dnsid CLI, dnsid record publish --domain <fqdn> fetches the canonical record content, signs it locally with your key, and prints the DNS records for you to publish—see the CLI command reference.

Verify your work

Once the record resolves, check it exactly as a counterparty would:

dnsid record verify --domain agent.example

or from code with VerifyDomain in any SDK. Verification exercises the whole chain—DNS resolution, record signature, JWKS fetch, status check, and lifecycle-log checks—so a passing verify confirms the record and log under the verifier’s configured trust policy.

Next steps

Key providersLocal keys, AWS KMS, and the key lifecycle.

Transparency logWire the lifecycle log your record points to.

Give an agent an identityThe record and its lifecycle.