Microsoft Foundry
A unified Azure platform for creating and managing AI models, agents, and applications with built‑in enterprise security, monitoring, and governance
Microsoft Foundry Hosted Agent cannot resolve its own Foundry endpoint — DNS failure during MCP initialization
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(25.6, 43%, 12%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJO%3C/text%3E%3C/svg%3E)
Janžo Jakub
0
Reputation points
We are experiencing a persistent DNS resolution issue with a Microsoft Foundry Hosted Agent deployed in Sweden Central.
Our Hosted Agent was working correctly on October 20, 2026, but started failing by October 26, without changes to the original deployed agent version.
Error
The agent fails during FoundryToolbox.connect():
MCP server failed to initialize:
[Errno -3] Temporary failure in name resolution
The container starts successfully, but the agent cannot initialize its Foundry Toolbox MCP connection.
Environment
- Microsoft Foundry Hosted Agent
Python 3.13
Microsoft Agent Framework
Foundry Toolbox connected to Azure AI Search
Region: Sweden Central
Public network access: Enabled (All networks)
Private Endpoint: Approved
Private DNS Zone: privatelink.services.ai.azure.com configured
VNet Injection: Not configured
Managed Virtual Network: Disabled
The issue is reproducible on both the original agent version and newly deployed versions.
Diagnostics performed
We added read-only DNS diagnostics directly inside the Hosted Agent container using Python socket.getaddrinfo().
Results:
| Hostname | Result |
aif-<resource>.services.ai.azure.com |
DNS resolution FAILED |
| Azure API Management hostname | DNS resolution OK |
The Foundry hostname consistently returns:
socket.gaierror: [Errno -3]
Temporary failure in name resolution
DNS resolution continues to fail after the container has been running for more than two minutes.
Additional findings:
Managed Identity authentication succeeds.
Foundry Storage API requests succeed.
The Hosted Agent container starts successfully.
The Foundry Toolbox MCP endpoint is accessible from our local machine.
Both MCP initialize and tools/list return HTTP 200 when invoked locally.
Azure Service Health shows no active service issues for our subscription.
We have not identified a relevant networking configuration change.
The deployed environment uses agent-framework-core 1.17.0, agent-framework-foundry-hosting 1.0.0b260821, and mcp 1.30.0.
Questions
Is there a known DNS resolution issue affecting Microsoft-managed Foundry Hosted Agent sandboxes in Sweden Central?
Why would the Hosted Agent container fail to resolve the Foundry project endpoint while other Azure service hostnames resolve correctly?
Could this be related to the combination of public network access and an existing Private Endpoint, even without VNet Injection?
Has there been any recent change to Hosted Agent networking or DNS behavior that could explain this regression?
A potentially related issue has also been reported here:
However, our case differs because we are not using VNet Injection, and the DNS failure persists well beyond container startup.We are experiencing a persistent DNS resolution issue with a Microsoft Foundry Hosted Agent deployed in Sweden Central.
Microsoft Foundry
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(304, 88%, 39%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EBS%3C/text%3E%3C/svg%3E)
Balantrapu Sreevishnu 0 Reputation points Microsoft External Staff2026-10-27T13:27:26.7633333+00:00 Hello @Janžo Jakub ,
Thank you for the detailed diagnostics. Your results point to a DNS problem inside the hosted agent sandbox, not to your agent code or authentication. I couldn't find any published advisory, known issue or documented change to hosted agent DNS behavior for Sweden Central.
Why only the Foundry hostname fails
[Errno -3] Temporary failure in name resolutionmeans the DNS server inside the sandbox didn't return an answer at all. It doesn't mean the name doesn't exist. Because your Foundry resource has an approved Private Endpoint, the public name<resource>.services.ai.azure.comredirects (through a CNAME) to<resource>.privatelink.services.ai.azure.com. If the sandbox can't follow that redirect, the Foundry hostname fails while other hostnames, such as Azure API Management, still resolve.Having a Private Endpoint while public access is enabled is a supported setup and shouldn't cause this error on its own. Your agent isn't VNet-injected, so it doesn't use your
privatelink.services.ai.azure.comPrivate DNS Zone and should resolve the public endpoint.Recommended steps
- Confirm the toolbox endpoint. Make sure
FoundryToolboxuses the public hostname in the documented format, not theprivatelinkhostname:https://<account>.services.ai.azure.com/api/projects/<project>/toolboxes/<toolbox-name>/mcp?api-version=v1 - Narrow down the failure inside the container:
import socket print(open("/etc/resolv.conf").read()) for h in ["<resource>.services.ai.azure.com", "<resource>.privatelink.services.ai.azure.com", "<resource>.cognitiveservices.azure.com"]: try: print(h, socket.getaddrinfo(h, 443)) except Exception as e: print(h, "FAILED", e)If only the
services.ai.azure.comorprivatelinknames fail, the sandbox can't follow the Private Link redirect.Optional isolation test. If your security policy allows it, test the same agent against a non-production Foundry resource that has no Private Endpoint. If DNS resolution works there, the Private Link redirect path is confirmed as the trigger.
Open an Azure support request under Microsoft Foundry > Agent Service. Include:
- Region
- Agent name and version
- Affected session IDs
- UTC timestamps of failed runs
- Sanitized diagnostic output
- Last working date (October 20) and the date failures started (October 26)
- Sanitized diagnostic output
- UTC timestamps of failed runs
- Affected session IDs
- Agent name and version
The VNet-injection thread you linked describes a brief DNS delay just after the sandbox starts. Your failure is persistent and happens without VNet injection, so adding startup retries or DNS warm-up won't fix it.
References
- Use a toolbox with a hosted agent
- Network isolation for a toolbox
- Configure network isolation for Microsoft Foundry
- Set up private networking for Foundry Agent Service
If this answer helped, please let me know.
Thank you.
- Confirm the toolbox endpoint. Make sure
Sign in to comment
Sign in to answer