Networking: DNS delay in VNet-injected hosted agent after sandbox start — Behavior and troubleshooting

Hi @ALOUANI Ilyan

Welcome to the Microsoft Q&A.

We are currently investigating the issue you reported. We kindly request that you allow us some additional time to complete our investigation.

We will provide you with an update as soon as we have further information.

Thank you for your continued patience and understanding.

ALOUANI Ilyan Hi & thx for join me at Q&A platform,

consistent 5–13 second delay after each sandbox starts is the most interesting part here. This looks more like a sandbox networking initialization or DNS path readiness issue than a general connectivity problem, especially bc public TCP traffic works immediately while UDP/53 to ur hub firewall doesn't.

With Azure AI Foundry hosted agents using VNet injection, there's an important distinction between the sandbox being started and its private network path being fully usable. However, I'm not aware of a documented 5–13 second DNS initialization delay that should be considered normal behavior. I'd treat this as something worth investigating rather than assuming it's an expected platform limitation.

One thing I'd check is whether UDP/53 is actually being dropped during those first seconds, or whether the DNS request reaches the firewall but the response doesn't make it back. Those are different problems. The first could indicate route or network readiness, while the second could point toward asymmetric routing, firewall state handling, or a return-path issue.

I'd run a timestamped DNS test from inside a newly started sandbox, querying the hub firewall directly over UDP and then TCP against the same DNS endpoint. If dig is available, compare dig @<firewall-ip> <private-name> +time=1 +tries=1 with the same command using +tcp. Also compare those results with the sandbox's default resolver. This should help separate DNS resolution problems from actual UDP connectivity problems.

The fact that adding the route table made the issue more frequent is another useful clue. I'd review the UDR next-hop configuration, firewall routing, and return path for traffic originating from the agent subnet. Also check the VNet's effective DNS configuration and whether the firewall's DNS proxy is ready to accept requests. An NSG allowing UDP/53 doesn't necessarily guarantee that the complete DNS path is working.

On the firewall side, I'd capture timestamped DNS proxy logs and network flow information during a fresh sandbox startup. If the firewall doesn't see the initial requests, the problem is likely upstream of it. If requests arrive immediately but responses are delayed or dropped, the investigation shifts toward the firewall or return path.

Regarding DNS warm-up, it can help with cold caches, but it won't fix a network path that isn't ready yet. If ur agent needs private DNS before processing its first request, a bounded readiness check that waits for successful private DNS resolution could mitigate the user-visible delay. That would be a workaround, tho, not a resolution of the underlying issue.

I'd also open a support case with the Microsoft Foundry Agent Service team, ideally involving Azure Networking engineering. Provide the sandbox startup timestamps, first successful UDP DNS query, firewall observations, region, subnet and route-table configuration, and affected agent identifiers. Ask them to confirm whether VNet injection has a known network-readiness window and whether sandbox readiness is expected to include private DNS connectivity.

One question: during those first 5–13 seconds, does DNS over TCP/53 to the same hub firewall work, or have u only confirmed general public TCP connectivity? That distinction would narrow this down quite a bit.

rgds,

Alex

p.s. if my answer is help - pls mark it as an answer

Hi ALOUANI Ilyan,

Thank you for providing the details. To further investigate the delay, we recommend validating the following Azure Firewall and DNS settings:

If Azure Firewall DNS proxy is enabled, confirm that the agent VNet is configured to use the Azure Firewall private IP as its DNS server.

Verify that all upstream DNS servers configured on Azure Firewall are reachable and can consistently resolve the required private DNS records.

If multiple upstream DNS servers are configured, ensure that all servers can resolve the same private records. This helps avoid intermittent resolution failures.

Enable and review Azure Firewall DNS Flow Trace logs during the initial 5–13-second window. This will help determine whether the DNS queries are reaching Azure Firewall and whether responses are being returned.

Correlate the DNS logs with the sandbox/session ID and UTC timestamp for an affected invocation.

Please share the relevant firewall DNS logs and timestamps from an affected test. Based on these results, we can determine whether further investigation is required from the Azure Firewall side or the Azure AI Foundry hosted-agent side.

We are experiencing a potentially related DNS resolution issue with Microsoft Foundry Hosted Agents in Sweden Central.

Our Hosted Agent was working on October 20, 2026, but started failing by October 26 without changes to the original deployed agent version.

The agent fails during FoundryToolbox.connect() with:

MCP server failed to initialize: [Errno -3] Temporary failure in name resolution

We confirmed the issue directly inside the Hosted Agent container using Python socket.getaddrinfo():

aif-<resource>.services.ai.azure.com → DNS resolution fails

Our Azure API Management hostname → DNS resolution succeeds

DNS resolution still fails after more than two minutes of container uptime

• The Foundry Toolbox MCP endpoint is reachable from our local machine, and both initialize and tools/list return HTTP 200.

Our Foundry resource has public network access enabled and an approved Private Endpoint, but no VNet Injection or Managed Virtual Network configured.

Is there a known DNS resolution issue affecting Microsoft-managed Hosted Agent sandboxes, including deployments without VNet Injection?