Roll out DNS-AID across the enterprise.

Who this is for

Two readers in one document. Use the table of contents on the right to jump to whichever track matches your job today.

Prerequisites

Honest preconditions. If you don't have one of these, the alternative line tells you the smaller starting point.

The 30-day shape of a rollout

Three phases. Each one has a scope, exit criteria, and a Looking Glass check before you move on.

Architecture

Three parts: zones, identity, and what runs on top.

5a. Zone architecture & split-horizon

The first decision: one shared _agents zone, per-team delegations, or per-environment? The recommended pattern is split-horizon delegation: a parent zone owned by the platform team, with per-team and per-environment sub-zones delegated via NS records. Internal resolvers see internal zones (corp.acme); external partners see only the public zone (acme.com). Internal agents never resolve externally.

Naming convention: _<agent>._<protocol>._agents.<env>.<scope>.<domain>. For example:

• _orders._a2a._agents.prod.corp.acme — internal production A2A agent
• _support._mcp._agents.prod.acme.com — external production MCP agent
• _search._a2a._agents.dev.team-discovery.corp.acme — team-delegated dev agent

Multi-cloud and hybrid topology

DNS-AID fits multi-cloud naturally, because DNS already crosses cloud boundaries by design. The pattern: each cloud publishes its own sub-zone on the cloud's native DNS service. _agents.aws.corp.acme on Route 53, _agents.azure.corp.acme on Azure DNS, _agents.gcp.corp.acme on Cloud DNS, _agents.dc1.corp.acme on Infoblox or BIND on-prem. The parent zone, owned by the platform team, delegates to each sub-zone via NS records.

Cloud-to-cloud trust is then native. An agent in AWS resolves an agent in Azure through normal DNS recursion, and the DNSSEC chain validates across the cloud boundary. No per-cloud registry federation, no shared control plane, no synchronization job. This is where DNS-AID quietly wins over a central registry. A multi-cloud, hybrid, or post-M&A federated estate can establish trust between agent fleets just by signing zones. There's no registry to negotiate access to, and no plumbing to maintain between clouds.

5b. Identity & auth

DNS-AID publishes where an agent lives and what it claims to do. The agent itself enforces who can call it, with the gateway in front doing the same check. Identity is the load-bearing architectural decision in any rollout.

Human-to-agent vs. agent-to-agent

These are distinct identity flows. Human-to-agent uses interactive OIDC with PKCE, MFA, and conditional access. Agent-to-agent is M2M: short-lived tokens, no interactive consent, audience-bound to the called agent's realm. Mixing the two flows is the most common identity-design mistake in agent rollouts. Decide which one your IdP token represents and bind enforcement to it.

Workload identity is the foundation for M2M

SPIFFE/SPIRE is the mesh-native, vendor-neutral standard. The cloud-native equivalents (AWS IAM Roles for Service Accounts on EKS, Azure Workload Identity on AKS, GCP Workload Identity Federation) are the right starting points if you live entirely in one cloud. Either way the agent's runtime identity becomes the SPIFFE ID or cloud-IAM principal, and the IdP issues short-lived tokens bound to that identity. No long-lived secrets in code or config.

Realm parameter as audience scope

The realm SvcParamKey in the SVCB record (e.g. realm="prod") is the audience scope the agent will accept tokens for. Tokens issued for one realm must not be replayable against another. Treat realm as the token aud claim and validate it at the gateway and at the agent.

DANE/TLSA cert pinning

Where DNSSEC is in place, DANE/TLSA binds the agent's TLS certificate to DNS. That gives you cheap cert pinning with no separate PKI to operate. Where DNSSEC isn't available, fall back to a private CA plus SPIFFE X.509 SVIDs.

IdP outage behavior

What happens when Okta or Entra is down? Decide per-agent. Fail-closed is the default: the gateway returns 503 to callers when token validation can't complete. Fail-open with a tightly-scoped token cache may be acceptable for low-risk, high-availability agents. agentgateway exposes this as an ext_authz policy choice; make it deliberate, not accidental.

Token caching and revocation

Short token TTL (5–15 minutes), plus a revocation list propagated to the gateway. Don't let the SDK cache tokens past their TTL "for performance"; that turns a revocation event into a multi-hour incident.

5c. Upstream services that build on DNS-AID

If DNS-AID is the discovery substrate, what runs on top of it in your stack? Four categories.

Policy enforcement — six layers of defense in depth

Policy is not a single hook. It is six layers, advertised at publish time and enforced at every checkpoint between the caller's keyboard and the agent's RPC handler. Where the layers disagree, the most restrictive wins. The risk this guide is built to prevent is what happens when they disagree silently: policy drift.

Integration points by enforcement layer

For each of the six layers, the systems you can plug in. Everything listed is something you can install today.

Four patterns worth lifting wholesale

CEL → OPA lowering

The DNS-AID policy bundle's CEL rules can be transpiled to Rego, so the same policy document drives §6.3 (caller SDK) and §6.4/§6.5 (OPA-based server or gateway enforcement). Eliminates the worst form of drift: divergent rule languages saying almost-but-not-quite-the-same thing.

agentgateway + ext_authz + OPA chain

Reference architecture for §6.5: agentgateway terminates MCP/A2A, calls ext_authz against OPA, which evaluates the policy bundle fetched (with TTL) from the policy= URI in DNS. One bundle, two enforcement points, no extra config plane.

Internal policy registry pattern

The policy= URI should point into the org's central policy catalog (typically Backstage TechDocs or a homegrown portal) instead of being a one-off URL per agent. Security gets one place to audit and version policies, and §6.2 CI lint validates that the URI matches the registry's approved list.

DLP / PII scrubbing as a §6.5 plugin

For agents that handle regulated data, slot Microsoft Purview, AWS Macie, or Nightfall into the agentgateway pipeline as a payload-transform step. Policy as transform, not as binary allow/deny.

Governance & compliance

Who owns what, who approves what, and how the audit trail maps to the regulations your auditors actually ask about.

8.1 Ownership model

The platform / DNS team owns the parent _agents zone and the policy framework. Security owns the approved capability vocabulary and the IdP integration. Application teams own their delegated sub-zone and their per-agent policy URIs.

8.2 Onboarding & approval flow

A new agent published in a delegated zone passes through:

1. Capability declared from the approved vocabulary.
2. Policy URI present, CI-validated, and pointing into the org's internal policy registry — not a one-off URL.
3. Security review for cross-team callability.
4. Looking Glass shows green at dns-aid.org/looking-glass.

Same flow for new capabilities entering the shared vocabulary, gated by an architecture review.

8.3 Change management & versioning

Policy URIs are versioned (/policy/orders/v3.json); the SVCB record advertises the current version; TTLs are tuned so policy changes propagate within a known window; rollback is "revert the URI in the SVCB record." Same discipline for capability vocabularies.

8.4 Compliance mapping

This is a starting map for architects, not a sign-off. Consult your CISO and DPO for jurisdiction-specific evidence requirements. The DNS-AID artifacts below give compliance teams something concrete to point at.

8.5 The DNS-AID zone as your AI Bill of Materials

Walk the org's _agents zone and you get a live inventory of every AI agent in operation: what it does (capability), where it runs (endpoint), what protocol (alpn), who governs it (policy URI), what realm it serves. This is the AI-BoM that EU AI Act Annex IV technical documentation and NIST AI RMF Map-1.5 ask for.

Rather than maintain a parallel spreadsheet that goes stale the day after it's filed, point compliance audit at the live zone walk. The zone is signed, versioned, and timestamped; it cannot diverge from reality the way an audit spreadsheet does.

8.6 Cross-organization governance & partner onboarding

Federation across organizations is the hardest governance problem in agent ecosystems. DNS-AID's substrate makes it tractable; the contract work still has to happen. Onboarding sequence:

1. Trust anchor exchange. Partner shares their DNSSEC DS record (or zone trust anchor); your resolver chain validates them. If both orgs have public domains with DNSSEC, the public DNS root handles this implicitly.
2. Identity binding. DANE/TLSA pinning of partner agent certs in the partner zone; optional ANS PKI binding if both sides run ANS overlays. Document which certificate authorities each side accepts.
3. Capability vocabulary alignment. Agree on which capabilities cross the boundary. Best practice: a small shared subset, not the union of both vocabularies.
4. Policy contract. Out-of-band signed agreement (DPA, MSA addendum) referencing the specific policy URIs both sides advertise. Pin the URI versions in the contract.
5. Realm mapping. Decide which realms each side will issue and accept tokens for. Typically partners get a dedicated realm (realm="partner-acme") so blast radius is bounded.
6. Revocation procedure. Documented break-glass: zone owner unpublishes, callers see NXDOMAIN within TTL. Partner notification SLA. Joint tabletop exercise before going live.
7. Joint observability. Agreement on what telemetry crosses the boundary (typically: nothing payload, only allow/deny counts and aggregated latency).

This is one of the genuinely open areas of agent federation; the §11 threat model calls out residual risks. The level of detail above is what architects need to hand to legal. Anything thinner gets bounced from the contract review.

8.7 Decommissioning & audit trail

An agent's full lifecycle (publish, version bumps, deprecation, unpublish) leaves a DNS-zone audit trail; SIEM retains it. Stale-record hunters run weekly via a Looking Glass diff. Required for GDPR Art. 17 and SOC 2 CC6.7.

Operations

Publishing mechanics, scale, verification, and the SLOs you can copy into your runbook.

9.1 Publishing

The DNS provider question: Route 53 and Cloudflare reject private SvcParamKeys today, so DNS-AID's richer metadata can't ride in their SVCB records. Recommendation: Infoblox NIOS, BIND9, PowerDNS, or NS1 for internal zones where you want full SVCB expressiveness; _agentmeta TXT-record fallback for external public zones hosted on providers that don't yet accept the private keys. The fallback pattern is documented in Learn More.

9.2 Scale and resilience

DNS has been the internet's lookup system for forty years. It is distributed by design, decentralized by design, and has had every conceivable failure mode shaken out of it. Caching at the resolver, OS, and SDK layers means a hot lookup is typically sub-millisecond. There is no central control plane to bottleneck on, no synchronization job to fall behind.

Recommended TTLs: 300 seconds for capability and policy SVCB records (fast change), 3600 seconds for stable endpoint records. The agentgateway-to-DNS dependency is no more concerning than any service's dependency on DNS. Which is to say, not concerning. This is one of the rare places in the agent stack where the boring, well-understood substrate happens to be the right answer.

9.3 Verification with Looking Glass

Verify with the existing Looking Glass page at dns-aid.org/looking-glass. At each rollout phase, run the target domain through Looking Glass and confirm: agent record discovered, DNSSEC valid, DANE/TLSA valid where used, policy URI reachable, no WARN or ERROR findings.

There's no programmatic CI integration for Looking Glass today. Verification is a human checkpoint on a published URL. Teams that want CI-grade automation should pair manual Looking Glass spot-checks with dig or delv scripts and the dns-aid verify CLI run from CI.

9.4 Example SLOs

Starting targets architects can adopt or adjust. Calibrate against your own resolver and gateway baseline.

Phased rollout & RACI

Phase detail expands §4. Each phase has prerequisites (from §3), scope, exit criteria, and rollback. The RACI then sets ownership across the lifecycle.

10.1 Phase detail

Pilot — weeks 1–2

Prerequisites: §3.1–3.4 met for one team. Scope: one agent, internal zone only, one framework middleware wired up. Exit: agent discoverable via Looking Glass; one caller integrates end-to-end. Rollback: remove the SVCB record; revert framework middleware to no-op.

Canary — weeks 3–6

Prerequisites: pilot exit met; capability vocabulary v0.1 published; CI lint deployed. Scope: 3–5 agents across 2 teams; policy URIs wired at all six §6 layers; IdP integration live for caller SDK and target agents; agentgateway deployed for inter-team calls. Exit: deprecation exercise (publish v2 of an agent, drain v1, unpublish); policy update propagation verified within one TTL. Rollback: mesh routes bypass agentgateway; SDK falls back to discovery-only mode without enforcement.

Production — week 7+

Prerequisites: canary exit met; threat model (§11) reviewed and signed off; SLOs (§9.4) instrumented. Scope: platform team owns parent zone; teams self-serve via delegated sub-zones; SIEM and drift detection live; AI-BoM snapshotting on schedule (§8.5). Exit: partner onboarding playbook (§8.6) tested in tabletop; quarterly AI-BoM snapshot delivered. Rollback: per-team, not org-wide. Freeze new publishes in the affected sub-zone, fall back to canary-phase agentgateway routing.

10.2 RACI

R = Responsible (does the work) · A = Accountable (owns the outcome) · C = Consulted · I = Informed.

Threat model

A signpost threat model, not an exhaustive one. Run a full STRIDE or LINDDUN exercise during the canary phase with Security and AI Governance. The table below covers the threats this guide is designed to mitigate, and what residual risk remains.

Cost & migration

Directional budget input plus the playbook for moving off an existing service registry.

12.1 Cost — directional estimates

Commercial pricing varies by negotiation; these are open-source-leaning ballparks for budget input. The DNS-AID protocol itself is free.

Headcount is usually the dominant cost. Estimate 0.5 FTE platform engineer ongoing for zone + policy registry + drift monitoring, plus 0.25 FTE Security for capability vocabulary + audit. The pilot phase fits inside existing platform-team capacity at most enterprises.

12.2 Migration & coexistence

Greenfield is rare. Most enterprises start with some mix of hand-rolled service registries, MCP server URLs pinned in a Slack channel, and hardcoded endpoints in agent config. The shadow-publish migration pattern moves teams off the legacy without breakage.

1. Inventory. Catalog current agent endpoints (often spread across Slack, Confluence, hardcoded configs, internal portals). Bonus: this inventory exercise alone usually surfaces stale agents nobody remembered.
2. Shadow-publish. Publish DNS-AID records in parallel with the existing registry. Same endpoints, dual source of truth, no consumers switched yet.
3. Dual-resolve in the SDK. Update SDK or framework middleware to resolve from both sources, preferring DNS-AID, falling back to legacy. Log mismatches.
4. Cutover per team. Once a team's agents are shadow-published and validated via Looking Glass, switch their callers to DNS-AID-only. Telemetry should show zero fallback hits before declaring the team done.
5. Deprecate legacy. Freeze new entries to the old registry; set a sunset date; remove read paths once SLOs hold for one quarter.
6. Decommission. Old registry goes read-only, then offline. SIEM retains its records per audit policy.

Verification checklist & next steps

A short list to keep on the wall, and where to read next.

Verification checklist

• Target zones are DNSSEC-signed; resolver chain validates from root.
• Authoritative DNS supports private SvcParamKeys, or the _agentmeta TXT fallback is in place.
• Enterprise IdP issues short-lived tokens audience-bound to the agent's realm.
• Workload identity (SPIFFE or cloud-native) is the foundation for M2M tokens.
• Policy URI is reachable, schema-valid, and points into the internal policy registry.
• CI lint blocks bad publishes before merge.
• agentgateway or mesh enforces independent of agent SDK; ext_authz chain wired to the policy bundle.
• SIEM subscribed to zone-change events; drift detector running against approved baselines.
• Looking Glass green at dns-aid.org/looking-glass for every published agent.
• Threat model reviewed; partner onboarding playbook tested in tabletop.

Next steps

• Looking Glass — verify your agents are discoverable and DNSSEC-valid.
• Policy — deeper governance and CEL rule mechanics.
• Learn More — protocol mechanics, SVCB anatomy, DNSSEC chapter.
• OWASP ANS specification — for orgs adding the PKI/naming overlay.
• agentgateway project — the §6.5 reference gateway.
• DNS-AID core (GitHub) — SDK, CLI, integrations, IETF draft references.