Status & freshness

Every identity record points at a status URL (su=), and verifiers must see a fresh, ACTIVE status to trust an agent. Whoever operates that URL determines how quickly revocations and other state changes propagate. For a self-managed identity, that is you.

What verifiers see after a revocation

Revoking an identity, with dnsid revoke or from code, should change every public surface at once. This is what the SDKs and verifiers expect:

Surface	After revocation
Status URL (su=)	Serves REVOKED immediately
JWKS (ku=)	Returns 410 Gone with a {"status":"revoked"} tombstone instead of the key
VerifyDomain	Fails with status_not_active (see Verification results)
Lifecycle log	Records a signed REVOCATION event with the reason code, independently verifiable forever
dnsid status	Shows REVOKED; the state is terminal
The domain	Reusable for a new identity (fresh keys, fresh lifecycle) unless blocked for policy violations

Cached verifiers observe the change on their next status or JWKS refresh, so the cache lifetime you serve sets the window. Every row above except the lifecycle log is your infrastructure’s responsibility. That is the subject of the rest of this page.

Operator-managed status URLs

Any self-managed su= status URL is operated by the party hosting it. For domains you own, that is you. Verifiers fetch the status document from the signed su= URL and use whatever that host serves, so freshness after a revoke is an operational property of your hosting: your update path, CDN configuration, cache policy, and response headers. The URL may become current immediately, or it may keep serving ACTIVE until every cache in front of it expires.

Hosting a status endpoint well

• Update the status document promptly when an agent is revoked.
• Avoid cache headers and CDN rules that can preserve ACTIVE / READY responses after revoke.
• Prefer Cache-Control: no-store for revocation-sensitive status responses, or short/no-cache semantics when operational constraints require caching.
• After a revoke, confirm the change is actually observable: fetch the status URL raw, with curl for example, and run SDK verification against the domain, which is the path relying parties actually use. The two can disagree when a CDN or cache is still serving the old ACTIVE response.

Note

There is no dnsid renew command or background SDK renewer. Renewal is just re-publication, governed by the TXT profile and publication workflows. Self-managed records are maintained by the domain owner, as described in Give an agent an identity.

Next steps

Give an agent an identityThe record lifecycle and who maintains it.

Publish self-managed recordsHosting the JWKS and status endpoints yourself.

Verification resultsThe codes verifiers return, including status_not_active.