Transient DNS resolution failure to platform endpoint 168.xx.xx.xx— VM

Question

Transient DNS resolution failure to platform endpoint 168.xx.xx.xx— VM

Archana Chandran 0

On 2026-10-09 between 04:35:05 and 04:49:53 UTC, VM experienced continuous DNS resolution timeouts. The VM's only configured nameserver is 168.XX.XXX.XX. We have ruled out disk exhaustion, memory/OOM, connection tracking table exhaustion, and ARP/neighbor table overflow on the guest OS. Resource Health for this VM shows no platform fault during this window — only our own subsequent manual reboot at 04:49–04:51 UTC, which resolved the issue. We would like to understand whether there was a host-side or SDN-level event affecting this VM's connectivity to the platform DNS relay during this window.

Secondary/lower-priority note: the VM has also logged recurring page_pool_release_retry() stalled pool shutdown kernel messages on the hv_netvsc interface since approximately October 2, continuously and unchanged — unrelated to the acute incident but possibly worth a look.

We were able to fix the issue by restarting the server but would like to understand why a transient loss of connectivity to Azure's platform DNS relay happened.

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Alex Burlachenko 25,370 MVP Volunteer Moderator

Hi Archana Chandran & thx for join me at Q&A platform,

if the address is 168.63.129.16, that's Azure's platform virtual IP used for Azure-provided DNS and other infrastructure services. A timeout reaching it can indicate a problem in the VM's networking path, but it doesn't automatically mean there was an Azure host or SDN outage. One important Resource Health showing no platform fault doesn't rule out a transient networking issue. It also doesn't confirm one. And the fact that a reboot fixed it could point to either a temporary platform-side condition or something stuck in the guest's networking stack.

I'd pay some attention to those hv_netvsc messages, even tho they started earlier. They're related to the Hyper-V network driver, and recurring page_pool_release_retry() warnings are worth investigating alongside the DNS timeouts. I'd check the kernel logs around 04:35 04:50 UTC for interface resets, driver warnings, link changes, or packet drops. Also worth checking whether other outbound connections failed during that window or only DNS queries.

If this happens again, a packet capture showing DNS requests to 168.63.129.16 leaving the VM without responses would be especially useful. Comparing UDP and TCP port 53 could help narrow it down too.

For the October 9 incident, I'd open an Azure VM networking support case and ask Microsoft to correlate 04:35:05–04:49:53 UTC with host networking, SDN, and platform DNS telemetry. Include the VM resource ID, region, guest OS/kernel version, and relevant hv_netvsc logs.Unfortunately, there's no customer accessible log that can definitively confirm a host-side DNS relay failure after the fact. That part needs Azure engineering to investigate. I wouldn't treat the reboot as proof that the root cause was fixed, either.

rgds,

Alex

Archana Chandran 0 Reputation points

2026-10-09T11:52:33.44+00:00

Hi @Alex Burlachenko ,

Thanks for the detailed response — really helpful

A couple of updates since my original post:

We did find direct, explicit evidence rather than just an inference. The Azure Linux Agent (waagent) log shows repeated entries like this throughout the window:

[ProtocolError] [Wireserver Exception] [HttpError] [HTTP Failed] GET 168.63.129.16/machine/ -- IOError timed out -- 6 attempts made

firing roughly every minute from 04:39:39 to 04:49:44 UTC, stopping only when we rebooted at 04:49:48, and recovering cleanly at 04:51:27 with zero further errors. At 04:41:34 UTC waagent also logged an IMDS_CONNECTION_ERROR (169.254.169.254 unreachable), and one attempt at 04:46:37 UTC failed with “No route to host” rather than a plain timeout. So this wasn’t just DNS — it looks like broader loss of connectivity to Azure’s platform network path during that window.

I did take your suggestion on the hv_netvsc / page_pool_release_retry messages and checked them specifically against the incident window (04:00–05:30 UTC). Result: zero occurrences of that message in that window, and no NIC reset / link-down / carrier-change events logged anywhere between 04:35 and the reboot at 04:51 — the only networking log entries in that range are the post-reboot bring-up sequence. So that message appears unrelated to this incident rather than a contributing factor; it’s a separate, pre-existing background condition on this VM.
Alex Burlachenko 25,370 Reputation points MVP Volunteer Moderator

2026-10-09T12:23:12.9133333+00:00

Thanks for digging into those logs, Archana. This changes the picture quite a bit. The repeated WireServer failures to 168.63.129.16, together with the IMDS connection error to 169.254.169.254, confirm that the VM was having trouble reaching multiple Azure platform endpoints, not just resolving DNS. And I agree about hv_netvsc with no related messages or NIC events during the incident, I wouldn't treat those older warnings as a likely cause rn.

The "No route to host" error at 04:46:37 is particularly interesting. Unlike a simple timeout, it suggests that at least one connection attempt encountered a routing or network reachability failure. That said, it still doesn't prove an Azure host or SDN issue. A temporary problem with guest routing, DHCP state, or local networking could produce similar symptoms without logging a NIC reset or link-down event.

What makes this worth escalating is the combination of failures across two platform endpoints, their timing, and the immediate recovery after reboot. I'd open a support case with the Azure VM Networking team and specifically request a host/fabric networking investigation for October 9, 04:35:05–04:49:53 UTC. Include the waagent excerpts, the IMDS failure at 04:41:34, the routing error at 04:46:37, and the recovery at 04:51:27.

I'd also ask Microsoft to check whether there were any host networking, virtual switch, or platform endpoint connectivity events affecting that VM during the window.

If it happens again, try capturing ip route get for both endpoints, a packet trace, and the current interface counters before rebooting. That should help distinguish packets not leaving the guest from packets leaving but never getting a response.

At this point, ur logs establish a broader platform-endpoint connectivity failure from the VM's perspective. The remaining question is where that failure originated, and that's what Microsoft needs to correlate with its internal telemetry.
if my answer help - mark it as an answer,
thx, Alex