Skip to content
All InsightsCloud Ops

Addressing DNS-Related Internet Issues in Azure VMs

Jagjeet Singh

“The internet is down on this VM” is one of the most misleading tickets in cloud operations. Far more often, the network is fine and DNS resolution is the culprit — the VM simply can’t turn names into addresses. Here’s a systematic way to confirm that and fix it on Azure virtual machines.

First, separate connectivity from resolution

Before touching DNS, prove where the failure is:

# Does raw IP connectivity work? (bypasses DNS entirely)
ping 8.8.8.8

# Does name resolution work?
nslookup microsoft.com

If pinging an IP succeeds but nslookup fails, you have a DNS problem, not a connectivity problem. This one distinction saves hours of chasing the wrong layer.

The usual Azure culprits

  • Custom DNS servers set at the VNet level. Azure VMs inherit DNS settings from their virtual network. If someone configured custom DNS servers (a domain controller, a filtering service) that are now unreachable or misconfigured, every VM in the VNet loses resolution. Check Virtual network → DNS servers.
  • The VM overriding DNS locally. A static resolver configured inside the guest OS can override Azure-provided DNS. On Linux, inspect /etc/resolv.conf; on Windows, check the adapter’s DNS settings.
  • Azure-provided DNS (168.63.129.16) blocked. This special address provides DNS and platform services. If an NSG rule or local firewall blocks it, resolution breaks in confusing ways.
  • Private DNS zones not linked. For private endpoints, resolution fails if the Private DNS Zone isn’t linked to the VNet.

A repeatable fix sequence

  1. Confirm the layer with the ping-vs-nslookup test above.
  2. Check VNet DNS settings — if custom servers are set and failing, revert to Default (Azure-provided) to isolate the cause.
  3. Inspect the guest OS resolver for a stale or hardcoded override.
  4. Verify NSGs and firewalls aren’t blocking 168.63.129.16 or port 53.
  5. Flush and retest — ipconfig /flushdns (Windows) or restart systemd-resolved (Linux).

Make it not happen again

DNS misconfigurations usually trace back to an undocumented change. Continuous configuration monitoring — knowing when a VNet’s DNS setting changed and who changed it — turns a two-hour investigation into a two-minute answer.

Running client workloads in Azure and tired of these fire drills? We manage cloud infrastructure so you don’t have to.

Scale your MSP with us.

Expert RMM engineers and dedicated technicians, ready to work inside your stack — without the hiring overhead.

Schedule a Free Call