Azure AI Foundry Agent Service - Data Proxy cannot resolve private Container Apps DNS for private MCP servers in BYO VNet setup

─────────────────────────────────────────

ENVIRONMENT

─────────────────────────────────────────

• Azure AI Foundry Agent Service: Standard Agent Setup with BYO VNet
• Setup template: 19-hybrid-private-resources-agent-setup (Bicep)
• MCP server host: Azure Container Apps (internal-only ingress, dedicated mcp-subnet)
• Region: Australia East
• SDK: azure-ai-projects 2.0.0b4 (Python)
• Capability host provisioning state: Succeeded
• customerSubnet: configured on account-level capability host

─────────────────────────────────────────

WHAT I AM TRYING TO DO

─────────────────────────────────────────

Deploy a private MCP server inside a VNet and connect it as a tool to a Foundry agent using the Standard Agent Setup with BYO VNet (template 19-hybrid-private-resources-agent-setup), as documented here:

https://dori-uw-1.kuma-moon.com/en-us/azure/foundry/agents/how-to/tools/model-context-protocol

The documentation states that private MCP is supported with Standard Agent Setup:

"Private endpoints: Connect to MCP servers that aren't exposed to the public internet. Private MCP requires Standard Agent Setup with private networking and a dedicated MCP subnet within your virtual network."

And the tool support table confirms:

"MCP Tool (Private MCP) | ✅ Supported | Through your VNet subnet"

─────────────────────────────────────────

INFRASTRUCTURE SETUP

─────────────────────────────────────────

VNet: 10.0.0.0/16 with four subnets:

• agent-subnet (10.0.0.0/24) — delegated to Microsoft.App/environments, used for Foundry agent runtime injection
• pe-subnet (10.0.1.0/24) — private endpoints for Foundry, CosmosDB, Storage, AI Search & VM
• mcp-subnet (10.0.2.0/24) — delegated to Microsoft.App/environments, hosts the private MCP server ACA environment

MCP server deployment:

• Azure Container Apps environment on mcp-subnet with --internal-only true
• Container app deployed with --ingress internal, --target-port 8080

Private DNS configuration:

• Private DNS zone created for default domain of ACA MCP server
• DNS zone linked to VNet
• Wildcard A record: * → Static IP address of MCP server

Foundry capability host (account-level):

• capabilityHostKind: Agents
• customerSubnet: .../subnets/agent-subnet
• provisioningState: Succeeded

─────────────────────────────────────────

VALIDATION FROM WITHIN THE VNET

─────────────────────────────────────────

From a Windows jump box VM deployed in pe-subnet, the private MCP server is fully reachable and working:

1. DNS resolution: Resolve-DnsName <MCP_SERVER_URL> → Resolves to <MCP_SERVER_STATIC_IP> ✅
2. TCP connectivity: Test-NetConnection ... -Port 443 → TcpTestSucceeded: True ✅
3. MCP initialize request: Invoke-WebRequest (POST /noauth/mcp with initialize payload) → HTTP 200 OK → Returns valid mcp-session-id header → Full MCP handshake successful ✅

This confirms the private MCP server, DNS configuration, and network routing are all correctly configured within the VNet.

─────────────────────────────────────────

THE PROBLEM

─────────────────────────────────────────

When a Foundry agent attempts to enumerate tools from the private MCP server, the following error is returned:

HTTP 400

{

"error": {

"message": "Error encountered while enumerating tools from remote server <MCP_SERVER_URL>:443/noauth/mcp. Details: Name or service not known (<MCP_SERVER_URL>:443)",

"type": "invalid_request_error",

"code": "tool_user_error"

}

}

The error is "Name or service not known" — a DNS resolution failure. The agent can be created successfully with the MCPTool configuration, but tool enumeration fails immediately when the agent is invoked.

─────────────────────────────────────────

WHAT WAS TRIED

─────────────────────────────────────────

1. Both --ingress internal (FQDN with .internal. prefix) and --ingress external (FQDN without .internal. prefix) on the internal ACA environment — same error.
2. Microsoft's own pre-built multi-auth MCP test image (retrievaltestacr.azurecr.io/multi-auth-mcp/api-multi-auth-mcp-env:latest) deployed as the MCP server instead of our custom server — same DNS error. This rules out MCP server implementation as the cause.
3. Set VNet DNS server explicitly to Azure DNS IP (168.63.129.16) — no change.
4. Tested via both the Foundry portal and the Python SDK — same failure from both paths.
5. The same MCP server URL works perfectly when the ACA environment is public (non-internal), confirming the issue is specific to private/internal ACA DNS resolution.

─────────────────────────────────────────

ROOT CAUSE HYPOTHESIS

─────────────────────────────────────────

The Foundry Agent Service appears to use an internal component (referred to as the "Data Proxy" in the platform) to route MCP tool calls. This component appears to resolve DNS from Microsoft's managed infrastructure rather than from within the customer's injected VNet subnet. As a result it cannot resolve private Container Apps FQDNs that are only visible via the customer's private DNS zones linked to the VNet.

This hypothesis is supported by Microsoft's own test script in the 19-hybrid-private-resources-agent-setup template (tests/test_mcp_tools_agents_v2.py), which explicitly handles this as a known failure:

   elif "424" in error_str or "Failed Dependency" in error_str:
      print("  ⚠ Known Issue: DNS Resolution")

      print("  Data Proxy cannot resolve private Container Apps DNS.")
```And in the template's test results table:

  "Private MCP via Data Proxy | DNS resolution issues for Container Apps | 

   Use public MCP server"

**─────────────────────────────────────────**

QUESTIONS

─────────────────────────────────────────

1. Is this a known platform bug that is being actively worked on? If so, is there an estimated timeline for a fix?

1. Is there a specific DNS zone format or FQDN format required for the Data Proxy to resolve private Container Apps endpoints — for example, a different zone name or a custom domain on the Container App?

1. Is the Data Proxy expected to perform DNS resolution through the customer's injected agent subnet, or does it always resolve from Microsoft's infrastructure? If the latter, is there a mechanism to configure the Data Proxy's DNS resolver to use the customer's VNet DNS?

1. Is there a validated workaround for private MCP server connectivity that does not require exposing the MCP server publicly — for example, using Azure API Management as a public proxy in front of the private MCP server?

**─────────────────────────────────────────**

REFERENCES

─────────────────────────────────────────

- MCP tool documentation:

  [https://dori-uw-1.kuma-moon.com/en-us/azure/foundry/agents/how-to/tools/model-context-protocol](https://dori-uw-1.kuma-moon.com/en-us/azure/foundry/agents/how-to/tools/model-context-protocol)
  
- Private networking for Foundry Agent Service:

  [https://dori-uw-1.kuma-moon.com/en-us/azure/foundry/agents/how-to/virtual-networks](https://dori-uw-1.kuma-moon.com/en-us/azure/foundry/agents/how-to/virtual-networks)
  
- Agent tools with network isolation:

  [https://dori-uw-1.kuma-moon.com/en-us/azure/foundry/how-to/configure-private-link#tool-support-and-traffic-flow](https://dori-uw-1.kuma-moon.com/en-us/azure/foundry/how-to/configure-private-link#tool-support-and-traffic-flow)
  
- 19-hybrid-private-resources-agent-setup template:

  [https://github.com/microsoft-foundry/foundry-samples/tree/main/infrastructure/infrastructure-setup-bicep/19-hybrid-private-resources-agent-setup](https://github.com/microsoft-foundry/foundry-samples/tree/main/infrastructure/infrastructure-setup-bicep/19-hybrid-private-resources-agent-setup)
  
- Testing guide (contains known issue acknowledgement):

  [https://github.com/microsoft-foundry/foundry-samples/blob/main/infrastructure/infrastructure-setup-bicep/19-hybrid-private-resources-agent-setup/tests/TESTING-GUIDE.md](https://github.com/microsoft-foundry/foundry-samples/blob/main/infrastructure/infrastructure-setup-bicep/19-hybrid-private-resources-agent-setup/tests/TESTING-GUIDE.md)