The prevailing "allow-all-outbound-DNS" posture in many agent runtime deployments is a significant compliance gap, often rationalized as necessary for functionality. From an audit perspective, this is indefensible. It creates an unmonitored data exfiltration channel and allows agents to bypass your meticulously crafted network allowlists by resolving to arbitrary, non-allowlisted IP addresses.

The principle must be: DNS is a control plane for network access, not an exception to it. Therefore, the objective is to enforce a strict DNS allowlist, typically at the host or container network policy layer, permitting resolution only through your organization's designated internal resolvers.

**Implementation Checklist:**
* **Define Authoritative Resolvers:** Restrict outbound UDP/TCP port 53 and 853 (DoT) to a maximum of two or three internal resolver IPs (e.g., your enterprise DNS servers, a dedicated VPC resolver).
* **Block External Resolver IPs:** Explicitly block all public DNS resolver IP ranges (e.g., 8.8.8.0/24, 1.1.1.0/24, etc.). This prevents hardcoded bypass attempts.
* **Enforce at the Runtime Level:** Apply these rules at the orchestration layer (e.g., Kubernetes NetworkPolicy, AWS Security Groups for task definitions, host firewall). Do not rely on agent configuration alone.
* **Mandate Internal Resolution:** Configure the agent runtime (e.g., via `resolv.conf`, container DNS settings) to use only the allowed internal resolvers. This provides defense-in-depth.
* **Log and Alert on Violations:** Ensure firewall/network policy logs for denied DNS attempts are aggregated and have alerts for anomalous volumes. This is a key SOC 2 CC7.x and ISO 27001 A.12.4.x control.

**Common Challenges and Mitigations:**
* **Agent Demands for Public DNS:** If an agent vendor's documentation insists on public DNS, treat this as a high-risk finding in your vendor assessment. Test thoroughly with internal resolution; the requirement is often false.
* **Service Discovery:** If agents require internal service discovery (e.g., via SRV records), your internal DNS infrastructure must support it. This is not a valid reason to allow public DNS.
* **Dynamic Dependency Updates:** The primary argument for lax DNS is "agents need to contact new services." This is a software supply chain concern. All external dependencies should be identified during procurement/sign-off and added to your network allowlist *before* deployment. The DNS policy then enforces this catalog.

The operational burden is managing the dependency catalog, not the DNS policy. The policy is the static control that ensures the catalog is effective. Without it, your network allowlist is largely ceremonial.

-- grace