Skip to main content

Troubleshooting Lab: Configure public and private DNS zones

Diagnostic Scenarios​

Scenario 1 — Root Cause​

A team reports that newly created VMs in VNet-Prod are not being automatically registered in the private DNS zone srv.interno.azure. The environment was configured three weeks ago and worked correctly until two days ago, when a new group of VMs was added.

The administrator checks the current state of the zone and linkage:

# Output from command: az network private-dns link vnet list
# --zone-name srv.interno.azure --resource-group rg-dns

Name              VirtualNetwork    RegistrationEnabled    ProvisioningState
----------------  ----------------  ---------------------  ---------------
link-prod         VNet-Prod         False                  Succeeded
link-dev          VNet-Dev          True                   Succeeded

Additional information collected by the team:

  • Old VMs from VNet-Prod appear normally in the zone
  • The NSG of the new VMs subnet blocks outbound port 53 UDP
  • New VMs receive IP via DHCP without problems
  • VNet-Dev has auto-registration active and works correctly

What is the root cause of the automatic registration failure for new VMs?

A. The NSG is blocking DNS queries on port 53 UDP, preventing the platform from registering the names

B. The automatic record limit per private zone has been reached with the addition of the new VM group

C. Auto-registration is disabled on the VNet-Prod linkage, so no new VMs from this VNet will be automatically registered

D. The zone srv.interno.azure is in an incomplete provisioning state, preventing new records

Scenario 2 — Action Decision​

A network engineer has identified that name resolution for the domain pagamentos.contoso.com is failing for on-premises servers. The cause has already been diagnosed: the conditional forwarder in the on-premises DNS points to 168.63.129.16, which is not accessible outside the Azure network. The private DNS zone pagamentos.contoso.com exists in Azure and is correctly linked to the production VNet.

Operational context:

  • The on-premises environment is connected to Azure via ExpressRoute with active private peering
  • An Azure DNS Private Resolver is already provisioned in a production VNet subnet, with an inbound endpoint at IP 10.10.5.4
  • The scheduled maintenance window starts in 40 minutes
  • Changing on-premises DNS records requires change request approval, which has already been issued for this window

What is the correct action to take now?

A. Create an NS record in the public zone contoso.com delegating pagamentos.contoso.com to Azure DNS nameservers

B. Update the conditional forwarder in the on-premises DNS to point to 10.10.5.4 instead of 168.63.129.16

C. Reconfigure the DNS Private Resolver inbound endpoint to use the IP 168.63.129.16 directly

D. Create a new VNet link in the private zone with auto-registration enabled to cover on-premises traffic

Scenario 3 — Root Cause​

A multi-region application uses two VNets: VNet-EastUS and VNet-WestEU. Both are linked to the private DNS zone app.plataforma.azure. Auto-registration is enabled on both linkages. VMs in VNet-EastUS resolve names of VMs in VNet-WestEU without problems.

The team reports that a specific VM, cache-01, created in VNet-EastUS, cannot be resolved by either VNet. The administrator queries the zone:

# az network private-dns record-set list \
# --zone-name app.plataforma.azure \
# --resource-group rg-dns-global \
# --query "[].{Name:name, Type:type}" -o table

Name              Type
----------------  ------
vm-app-01         A
vm-app-02         A
vm-db-01          A
cache-01          A

The administrator also checks:

# nslookup cache-01.app.plataforma.azure
# Executed from vm-app-01 (VNet-EastUS)

Server:  168.63.129.16
Address: 168.63.129.16

** server can't find cache-01.app.plataforma.azure: NXDOMAIN

Additional information:

  • cache-01 has private IP 10.1.4.22 and is running
  • The VM cache-01 was created from a custom image with static DNS configured on the NIC, pointing to 10.1.0.5 (legacy internal DNS server)
  • Server 10.1.0.5 does not forward queries to 168.63.129.16
  • Peering between VNet-EastUS and VNet-WestEU is active

What is the root cause of the problem?

A. Peering between VNets does not propagate DNS records from private zones; a separate link per VNet is required

B. The A record for cache-01 exists in the zone, but the VM does not respond to queries because the static DNS server configured on the NIC prevents the Azure platform from registering the correct IP, generating a record with inconsistent or empty IP

C. The NIC of cache-01 has static DNS pointing to a server that does not forward to 168.63.129.16, causing the VM itself to not be able to resolve names, but its record in the zone exists and is correct

D. Auto-registration created the record for cache-01 in the zone, but since the VM uses static DNS on the NIC, Azure could not register the correct IP, resulting in an A record with invalid or missing value

Scenario 4 — Diagnostic Sequence​

An administrator receives the following report: "VMs in VNet-Shared stopped resolving names for the domain interno.corp after a resource reorganization done yesterday."

The administrator has access to the Azure portal and the VMs. The available investigation steps are:

  1. Check if the private DNS zone interno.corp still exists in the correct resource group
  2. Execute nslookup interno.corp from an affected VM and record the DNS server response
  3. Confirm if VNet-Shared still appears in the VNet links list of the zone interno.corp
  4. Check if the DNS settings of VNet-Shared were changed to a custom server during the reorganization
  5. Test resolution of an external name like microsoft.com from the affected VM

What is the correct diagnostic sequence?

A. 1 → 3 → 4 → 2 → 5

B. 2 → 5 → 1 → 3 → 4

C. 4 → 1 → 3 → 2 → 5

D. 5 → 2 → 1 → 3 → 4

Answer Key and Explanations​

Answer Key — Scenario 1​

Answer: C

The command output is the decisive clue: RegistrationEnabled: False on the link-prod linkage. Disabled auto-registration means the Azure platform will not automatically create A/AAAA records for VMs from this VNet, regardless of how many VMs are added. The old VMs appear in the zone because they were registered when the linkage still had auto-registration active, or they were inserted manually.

The NSG blocking port 53 is irrelevant information included purposefully. Automatic registration of VMs in private DNS zones is done by the Azure platform internally, without depending on DNS traffic originating from the VM. Blocking port 53 prevents the VM from resolving names, but does not prevent Azure from registering its name.

Alternative B is a plausible distractor: there is a limit of 100 VNets with auto-registration per zone, but the relevant limit here is records per zone (250,000), not VNets. Additionally, the command output clearly shows the cause. The most dangerous distractor would be A: acting by removing the NSG would solve a different problem (resolution by the VM), leaving the real problem untouched.

Answer Key — Scenario 2​

Answer: B

The cause is already diagnosed and the correct technical solution is well known: the on-premises conditional forwarder must point to the DNS Private Resolver inbound endpoint, which is the only component accessible via ExpressRoute from the on-premises network. The IP 10.10.5.4 is already available and provisioned, the change already has change request approval and the maintenance window is active. All operational constraints are satisfied for this action.

Alternative A is technically incorrect for this scenario: creating an NS record in a public zone does not resolve names from a private DNS zone for on-premises clients. Alternative C is impossible: 168.63.129.16 is a virtual IP of the platform, not configurable on a resource. Alternative D confuses the purpose of VNet link (resolution within Azure) with the need for a forwarder for on-premises origin, and still would not solve the problem because the link does not expose an externally accessible endpoint.

Answer Key — Scenario 3​

Answer: D

The cache-01 record appears in the zone, but nslookup returns NXDOMAIN. This indicates that the record exists in the zone control plane, but the A record content is empty or contains a value that the resolver cannot return as valid. The cause is that auto-registration tries to capture the NIC IP via platform, but when the NIC has static DNS configured for an external server (10.1.0.5), the registration process may not be able to associate the correct IP with the entry, resulting in a malformed record or one without an associated IP value.

Alternative C is the most sophisticated distractor and represents the most common reasoning error: confusing the impact of static DNS on resolution performed by the VM itself with the impact on its registration in the zone. These are two independent mechanisms. The fact that server 10.1.0.5 does not forward to 168.63.129.16 explains why cache-01 cannot resolve other names, but does not explain why other VMs cannot resolve cache-01.

The information about active peering between VNets is irrelevant to the diagnosis: peering is necessary for data traffic, not for DNS resolution via shared private zone. Acting based on alternative A and creating additional links would not solve the problem and would add unnecessary complexity.

Answer Key — Scenario 4​

Answer: B

The correct sequence is: 2 → 5 → 1 → 3 → 4.

The correct diagnostic reasoning starts from the observable symptom and progressively eliminates hypotheses:

Step 2 confirms what exactly is failing and which DNS server the VM is querying. This differentiates between "the zone no longer exists" and "the VNet is no longer linked" and "the VNet DNS was changed".

Step 5 tests whether the problem is specific to the private zone or if DNS as a whole is broken on the VM. If microsoft.com resolves, basic DNS works and the problem is in the private zone. If it doesn't resolve, the VNet DNS was redirected to a non-functional server.

Step 1 verifies the zone's existence, confirming if the resource survived the reorganization.

Step 3 verifies if the VNet link with the zone still exists, which would be destroyed if the zone was moved between resource groups or if the link was deleted during the reorganization.

Step 4 confirms if the VNet DNS configuration was changed, which would be the cause if all previous steps showed healthy state.

Sequence A starts with zone existence before knowing what exactly is failing, which is inefficient. Sequence C starts with the most operationally costly step before any triage. Sequence D starts with an external DNS test without first capturing the specific symptom with nslookup.

Troubleshooting Tree: Configure public and private DNS zones​

100%
Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Legend:

  • Dark blue: initial symptom or entry point
  • Blue: diagnostic question, answered by direct observation
  • Red: identified root cause
  • Green: recommended action or resolution
  • Orange: intermediate verification before deepening the diagnosis

When facing a real problem, start from the root node and answer each question based on what is directly observable: command outputs, resource state in the portal, nslookup tests. Follow the path that corresponds to what you observed, without skipping steps. Each orange node indicates a validation moment before continuing: if the intermediate state is healthy, the problem is in a deeper layer. The red nodes name the cause with enough precision to guide the corresponding corrective action in the green node immediately below.