DNS-AID standardizes discovery and trust signaling around DNS. Policy sits one layer above that: some deployments attach additional policy material to discovery metadata, evaluate rules inside the caller or target runtime, and optionally add resolver-side or proxy-side enforcement where the infrastructure supports it.
Policy belongs near discovery, but not everything described on policy-heavy architecture diagrams is part of the core DNS-AID protocol. The most useful way to read the space is to separate discovery metadata, runtime evaluation, and optional infrastructure enforcement.
The public draft allows deployments to publish additional metadata and policy pointers alongside discovery data. Exact semantics remain deployment-specific until they are standardized.
The public DNS-AID learning materials already describe runtime policy evaluation, including auth requirements, caller restrictions, availability windows, rate limits, and CEL-based rules.
Teams that operate their own DNS or traffic infrastructure can extend runtime policy with resolver-side allow or deny logic, audit logging, or payload inspection without changing the core discovery model.
The simplest DNS-AID setup can stop at runtime policy in the caller and target. More opinionated environments may add resolver-side or in-path controls, but those should be understood as deployment layers rather than protocol requirements.
If a deployment operates resolvers or DNS middleware capable of policy checks, simple allow or deny logic can run before the application connects. This is useful for domain-level gating, basic protocol restrictions, or environment-wide deny lists.
The caller runtime is where DNS-AID policy is easiest to reason about today: discover the target, resolve auth, fetch any deployment-specific policy bundle such as a policy.json resource, evaluate rules, and decide whether to proceed.
A target service can enforce its own policy independently of the caller's decisions. That is where teams typically validate caller identity, required auth, method access, or domain restrictions again at the receiving edge.
Some deployments may add a transparent proxy for request or response inspection, redaction, audit logging, or DLP-style controls. That can be powerful, but it is an infrastructure choice layered on top of DNS-AID rather than a current standardized DNS-AID component.
Read this as a sequence, not a feature grid. The current public DNS-AID story is discovery, auth, policy evaluation, protocol dispatch, and telemetry. Local payload inspection is shown here as an optional extension rather than a current requirement.
Current align with the runtime model already documented elsewhere on this site. Steps marked Extension or Deployment describe optional patterns teams may add locally.
Resolve the DNS-AID record, capture the endpoint, protocol hints, and any deployment-specific metadata needed to choose how the request should be made.
Use the discovered metadata to choose the right auth handler, connection shape, and protocol setup before assembling the outgoing request.
If the deployment publishes a policy bundle such as a policy.json resource, evaluate its built-in rules and CEL expressions before the call is allowed to proceed.
Translate the call into the right application protocol and attach the chosen auth scheme, headers, and request structure for the target service.
Some teams may add local request scanning for prompt injection, PII, or data loss checks before traffic leaves the caller's environment.
Send the request over the selected protocol and let the target runtime apply its own independent checks before returning a response.
Teams that need stronger data-handling controls may also scan or redact response content locally before passing it back to the caller.
Capture status, latency, policy outcomes, and any deployment-specific audit signals so future routing, operations, or incident review can use them.
These examples line up with the public DNS-AID learning materials more closely than speculative trust-scoring or custom-key schemes. Built-in rules do most of the work; CEL helps when you need a narrower runtime expression.
allowed_caller_domains: ["*.trusted.com"]
Restrict access to callers from approved domains or subdomains.
Built-in policyrequired_auth_types: ["oauth2", "bearer"]
Allow only specific authentication schemes for sensitive targets.
Built-in policyavailability: weekdays 09:00-17:00 UTC
Limit service use to known windows for staffing, cost, or governance reasons.
Built-in policyrate_limits: 100 requests/minute per caller
Prevent overload or abuse without changing discovery behavior.
Built-in policyrequire_dnssec: true
Make policy decisions sensitive to whether the DNS discovery path was validated.
Built-in policycaller.domain.endsWith(".trusted.com")
Use CEL when built-in rules are not enough and the decision depends on runtime context.
CEL exampleDNS-AID policy is easiest to reason about when it stays close to discovery metadata and runtime decisions. The alternative is a more centralized AI security stack that manages policy through a separate control plane.
Start with the runtime model, then add infrastructure controls only where they solve a real operational problem. The desktop table stays for quick comparison; smaller screens get stacked cards instead of a clipped scroll area.
| Layer | Where it runs | Best for | Status | SDK required |
|---|---|---|---|---|
| Resolver-side controls | DNS resolver or DNS middleware | Domain allow or deny lists, coarse protocol gating | Deployment-specific | No |
| Caller-side runtime | Calling agent process | Auth selection, policy bundle evaluation, protocol dispatch | Documented today | Caller |
| Target-side runtime | Target service or middleware | Independent caller checks, auth validation, method access | Documented pattern | Target |
| Proxy-side inspection | In-path infrastructure | Audit logging, inspection, redaction, DLP extensions | Optional extension | No |
DNS-AID is strongest when discovery remains simple and teams layer policy where it adds real value. Start with the documented runtime model, then add resolver or proxy controls only when your environment needs them.