Private DNS Zone not resolving on Linux VM but is able to resolve on Windows VM on the same Vnet

Question

Private DNS Zone not resolving on Linux VM but is able to resolve on Windows VM on the same Vnet

Gomolemo 105

I have a private dns zone linked to a vnet with 2 VMs. I am able to resolve records from Windows VM but on Linux VM i getting SERVFAIL response.

This is weird because I was able to resolve records from this Linux VM before, for some unknown reason is not working now.

I have tried to set DNS Server on the linux to use Azure DNS servers but still getting an error.

Gomolemo 105 Reputation points

2026-05-14T07:15:21.52+00:00

The linux response is coming from 127.0.0.0:53 but the Windows VM is coming from Azure DNS. These servers are on the same vnet using Azure DNS servers
Venkatesan S 8,410 Reputation points Microsoft External Staff Moderator

2026-05-14T07:23:51.4666667+00:00

Hi Gomolemo,

Thank you for contacting us about the Azure private DNS Zone issue. We have begun looking into it and will share our suggestions with you as soon as possible. If you have any additional details or concerns in the meantime, please let us know. We appreciate your patience while we work on this.

2 answers

Your answer

Gomolemo 105 Reputation points

2026-05-14T07:15:21.52+00:00

The linux response is coming from 127.0.0.0:53 but the Windows VM is coming from Azure DNS. These servers are on the same vnet using Azure DNS servers
Venkatesan S 8,410 Reputation points Microsoft External Staff Moderator

2026-05-14T07:23:51.4666667+00:00

Hi Gomolemo,

Thank you for contacting us about the Azure private DNS Zone issue. We have begun looking into it and will share our suggestions with you as soon as possible. If you have any additional details or concerns in the meantime, please let us know. We appreciate your patience while we work on this.

Answer 1

Hi Gomolemo,

Thanks for reaching out in Microsoft Q&A forum,

Your Linux VM's SERVFAIL issue with the private DNS zone likely stems from systemd-resolved overriding network DNS settings, causing queries to loop through the local stub resolver at 127.0.0.1:53 instead of reaching Azure's DNS at 168.63.129.16 like your Windows VM does. This commonly happens after OS updates or NetworkManager changes that reset configs, even if manual DNS server settings were applied—Linux distros handle VNet DNS integration differently than Windows.

Check systemd-resolved status: systemd-resolve --status or resolvectl status to confirm if your interface (eth0/ens160) lists 168.63.129.16 as the DNS server and shows the VNet domain suffix.
Test direct Azure DNS: dig @168.63.129.16 yourrecord.yourzone—success here but failure on plain dig yourrecord.yourzone points to local resolver problems.

Fix:

Flush and reset the resolver:

sudo systemd-resolve --flush-caches
sudo systemd-resolve --reset-server eth0
sudo systemd-resolve --set-dns=168.63.129.16 --interface=eth0
sudo systemctl restart systemd-resolved

Ensure resolv.conf links properly: sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf.

Verify VNet link in Azure Portal: Private DNS Zone > Virtual network links > confirm your VNet is connected with "Enabled" status.

Official docs:

Azure DNS troubleshooting for VMs: https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances
Linux VM DNS options: https://learn.microsoft.com/en-us/azure/virtual-machines/linux/azure-dns

Kindly let us know if the above helps or you need further assistance on this issue.

Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Gomolemo 105 Reputation points

2026-05-14T07:51:42.6566667+00:00

This worked. I am able to resolve the azure private dns zone records.
Venkatesan S 8,410 Reputation points Microsoft External Staff Moderator

2026-05-14T07:54:32.1133333+00:00

Hi Gomolemo,

Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Answer 2

Follow these steps to isolate and fix the issue on the Linux VM.

Verify the record actually resolves in Azure DNS

From any machine (or a web tool like digwebinterface), query the record against the Azure DNS name servers for the private zone and confirm:
- Zone name is correct.
- Record name and type are correct.
- The record returns an answer.
If it fails here, fix the record in the private DNS zone first.

Confirm the private DNS zone is correctly linked

In the Azure portal, open the private DNS zone.
Check Virtual network links and ensure:
- The VNet where both VMs reside is linked.
- If using multiple VNets, that the Linux VM’s VNet is also linked.
If using autoregistration, verify the Linux VM’s record exists in the zone.

Check DNS configuration on the Linux VM

On the Linux VM, inspect the DNS client configuration:
```
  cat /etc/resolv.conf
```
- Confirm the nameserver entries match the VNet DNS configuration (either Azure-provided or your custom DNS server IPs).
- If using a local cache like dnsmasq, ensure it’s running and correctly forwarding.

Test resolution and DNS server directly from the Linux VM

Test the failing FQDN:
```
  nslookup <record-fqdn>
```
If it fails, test explicitly against the DNS server configured for the VNet:
```
  nslookup <record-fqdn> <dns-server-ip>
```
- Get <dns-server-ip> from the VNet’s DNS servers setting or from resolv.conf.
If using Azure-provided DNS and this is an AKS/private-cluster-like scenario, also test directly against Azure DNS:
```
  nslookup <record-fqdn> 168.63.129.16
```
- If this works but the default nslookup fails, the custom DNS server isn’t forwarding correctly.

Verify DNS server reachability from the Linux VM

If nslookup <record-fqdn> <dns-server-ip> fails with SERVFAIL, check connectivity to the DNS server:
```
  nc -zv <dns-server-ip> 53
```
If this fails, there is a network, NSG, or firewall issue preventing the Linux VM from reaching the DNS server.

Adjust Linux DNS client retry behavior (if intermittent)

Linux default DNS retry can be slow and sometimes cause apparent failures. Recommended settings are 1-second timeout and 5 attempts.

Check current settings:

  cat /etc/resolv.conf

Look for:

  options timeout:1 attempts:5

Because /etc/resolv.conf is autogenerated, configure per distro:
- Ubuntu/Debian (resolvconf): add the options line to /etc/resolvconf/resolv.conf.d/tail and run:
```
    resolvconf -u
```
- RHEL (NetworkManager): add RES_OPTIONS="options timeout:1 attempts:5" to /etc/sysconfig/network-scripts/ifcfg-eth0 and restart NetworkManager:
```
    systemctl restart NetworkManager.service
```
- openSUSE/SLES (netconf): add timeout:1 attempts:5 to NETCONFIG_DNS_RESOLVER_OPTIONS="" in /etc/sysconfig/network/config, then:
```
    netconfig update
```

If using a local DNS cache (dnsmasq) on Linux

Ensure dnsmasq is installed, enabled, and started, and that /etc/resolv.conf points to the local cache (for example, 127.0.0.1) only if that is intended.
If misconfigured, either fix the forwarders or temporarily disable dnsmasq and point directly to the VNet DNS servers in the VM’s network configuration.

If Windows resolves and Linux does not, the most common causes are:

Different DNS server configuration on Linux (wrong nameserver or custom DNS not forwarding to Azure DNS).
DNS server not reachable from the Linux VM (NSG/firewall).
Linux DNS client retry/timeout behavior causing failures that don’t appear on Windows.

References:

Share via

Private DNS Zone not resolving on Linux VM but is able to resolve on Windows VM on the same Vnet

2 answers

Your answer