Technical Lab: Design name resolution inside a VNet
Questions
Question 1 — Multiple Choice
A platform team created a VNet called vnet-prod in the East US region. No DNS configuration was changed after creation. A VM in this VNet needs to resolve the name of another VM in the same VNet using the FQDN in the format vm-backend.internal.cloudapp.net.
Which statement correctly describes Azure's behavior in this scenario?
A) Resolution fails because FQDNs only work with explicitly configured private DNS zones.
B) Resolution works automatically because Azure internal DNS resolves names in the format <vm-name>.internal.cloudapp.net for VMs in the same VNet.
C) Resolution works but requires the VM to be manually registered with Azure DNS service.
D) Resolution fails because Azure internal DNS only resolves short names (hostnames), not FQDNs.
Question 2 — Technical Scenario
An architect is designing name resolution for a hybrid environment. VMs in vnet-hub need to resolve on-premises host names, while on-premises hosts need to resolve Azure VM names. She plans to use an Azure private DNS zone linked to vnet-hub.
The on-premises environment uses its own DNS servers. After implementation, Azure VMs can resolve on-premises names, but on-premises hosts cannot resolve Azure VM names.
What is the most likely cause of this asymmetric behavior?
A) Azure private DNS zone does not allow A records created automatically for VMs.
B) On-premises DNS servers cannot directly query the address 168.63.129.16, which is the Azure resolver and is only accessible from within the VNet.
C) The private DNS zone was not linked with auto-registration enabled, preventing bidirectional resolution.
D) Azure blocks DNS queries originating outside the VNet by default via NSG, requiring an explicit inbound rule on port 53.
Question 3 — True or False
An Azure private DNS zone linked to a VNet with auto-registration enabled automatically registers the FQDNs of all VMs in the VNet, including those created before the link was established.
Question 4 — Technical Scenario
An engineer configures the following scenario:
- VNet:
vnet-app(10.1.0.0/16) - Private DNS zone:
app.internal - Link created between the zone and
vnet-appwith auto-registration disabled - VNet custom DNS pointing to
10.1.0.4(a VM with Bind9)
After configuration, VMs in vnet-app cannot resolve manually created records in the app.internal zone.
nslookup svc-api.app.internal
Server: 10.1.0.4
Address: 10.1.0.4#53
** server can't find svc-api.app.internal: NXDOMAIN
What is the most likely cause of the failure?
A) Disabled auto-registration prevents the creation of any records in the private zone.
B) The custom DNS server (10.1.0.4) is not configured to forward queries for the app.internal zone to the Azure resolver (168.63.129.16).
C) The app.internal zone cannot be resolved within the VNet because the .internal suffix is reserved by Azure.
D) The link between the zone and VNet needs to be recreated with auto-registration enabled for any resolution to work.
Question 5 — Multiple Choice
Two VNets are in different regions: vnet-eastus and vnet-westus. They are connected via global VNet Peering. A private DNS zone called corp.internal is linked only to vnet-eastus with auto-registration enabled.
What happens when a VM in vnet-westus tries to resolve a name registered in corp.internal?
A) Resolution works automatically because VNet Peering propagates private DNS links between peered VNets.
B) Resolution fails because the corp.internal zone is not linked to vnet-westus, and VNet Peering does not extend private DNS zone links.
C) Resolution works only for A records but fails for CNAME records in the private zone.
D) Resolution fails because private DNS zones do not support VNets in different regions.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
Azure provides internal name resolution automatically for VMs within the same VNet, without any additional configuration. Names in the format <vm-name>.internal.cloudapp.net are resolved by Azure internal DNS using the special address 168.63.129.16.
The main misconception represented by the distractors is confusing Azure's automatic internal DNS with private DNS zones, which are a separate and configurable resource. Internal DNS already works by default for resolution between VMs in the same VNet. Option D reverses reality: internal DNS resolves both short hostnames and FQDNs in the internal.cloudapp.net format.
Answer Key — Question 2
Answer: B
The address 168.63.129.16 is the Azure DNS resolver and is only accessible from within an Azure VNet. On-premises DNS servers cannot reach this address directly via the internet or hybrid connections, making resolution unidirectional.
To enable bidirectional resolution, the correct architecture requires a DNS forwarder (usually a VM in Azure or the Azure DNS Private Resolver resource) that acts as an intermediary: on-premises servers send queries for the private zone to this forwarder, which in turn queries 168.63.129.16 and returns the response.
Option C is a common misconception: auto-registration only affects whether VMs are automatically registered in the zone, not the resolution capability itself. Option D confuses NSG with DNS plane access control, which operates at a different layer.
Answer Key — Question 3
Answer: True
When a link with auto-registration is created between a private DNS zone and a VNet, Azure automatically registers DNS records for all VMs in the VNet, including those that existed before the link was established. Azure scans existing network interfaces in the VNet and creates corresponding records in the private zone.
This behavior is relevant in migration scenarios: enabling auto-registration in a VNet with existing VMs does not require VMs to be recreated or restarted for their names to appear in the zone.
Answer Key — Question 4
Answer: B
When the VNet is configured with custom DNS, VMs use that server for all queries. The Bind9 server at 10.1.0.4 receives the query for svc-api.app.internal, but since it's not configured with a conditional forwarder for the app.internal zone pointing to 168.63.129.16, it tries to resolve on its own and returns NXDOMAIN.
Disabled auto-registration (option A) only affects automatic creation of VM records, but manually created records continue to exist and are resolved normally via 168.63.129.16. Option D is incorrect because the link between zone and VNet is what enables resolution via the Azure resolver, regardless of auto-registration.
Answer Key — Question 5
Answer: B
VNet Peering, even global peering between regions, does not propagate private DNS zone links. Each VNet needs to be individually linked to the private DNS zone for its VMs to use the Azure resolver (168.63.129.16) and query records from that zone.
Option A represents the most common misconception: assuming that peering creates a complete extension of network configuration, including DNS. In practice, DNS and peering are independent resources. Option D is incorrect because private DNS zones support links with VNets in any region, including different regions; the problem in this scenario is the absence of the link, not a geographical limitation.