Summary
- A new individual IETF draft proposes a DNS record linking an agent’s name to its operator’s OAuth client. Receivers demand a fresh, permission-free token when that record exists.
- Deleting the DNS record is a poor retirement switch: new receivers can treat the agent as unlinked. The operator must disable the OAuth client to stop new tokens, and account for tokens already issued.
Take down the nameplate and the guard may stop asking for the badge. That is the strange consequence of the Agent DNS-OAuth Link draft, dated 20 October. It proposes a DNS TXT record beneath an agent’s name, carrying the authorization server’s issuer, an OAuth client identifier and a dedicated audience. The record tells a receiver where to check whether the operator still authorizes this client. It is a signpost, not the switch.
The sender obtains a JWT access token from its own authorization server and presents it with a call. The receiver looks up the DNS record, fetches the issuer’s public keys and checks the token’s signature, client, audience and age. A valid link record makes the token mandatory. A malformed record makes the receiver refuse the call. With no record, the receiver applies its ordinary policy for an unlinked sender.
The record is deliberately narrow. The draft says the token must grant nothing; its audience must be dedicated to this proof and accepted by no resource server. The receiver must establish the sender’s agent name through a protected channel or a sender-constrained token, such as DPoP. After checking the link, it still decides locally what the agent may do. A DNS entry cannot give a remote operator permission inside somebody else’s service.
Now try to retire the agent by deleting its DNS TXT record. A receiver meeting the name for the first time finds no link and can proceed under its normal unlinked-sender policy. A receiver that previously saw a valid link should keep demanding the token through a failed lookup, until it successfully observes removal. That rule stops a DNS outage from quietly erasing the check. The draft states the key point plainly in its revocation section: removing the record is not the way to revoke the agent; it stops new receivers from requiring the token.
The operational switch is at the issuer. Disable the OAuth client and it cannot obtain new link tokens. Tokens already issued remain usable until their own expiry or the receiver’s maximum accepted age, with DNS and key caches also in the timing calculation. The draft recommends a maximum age of 120 minutes or less as a general default. For actions that can move money or change production systems quickly, it suggests a shorter 5–15 minute age chosen for that operation. These are proposed bounds, not measurements of a deployed system.
DNS is still a dangerous hinge. A forged record could point to an attacker-controlled client; a suppressed answer could make a linked name look unlinked to a receiver without memory. The draft calls for domain owners to sign zones and receivers to validate answers using DNSSEC. Its Datatracker record remains I-D Exists, an individual proposal rather than an adopted operating rule. The immediate test is a retirement drill: delete only the DNS record, then disable only the client, and record what new and previously linked receivers accept at each stage.
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance





