Technical Lab: Configure DNS settings for a VNet
Questions
Question 1 — Multiple Choice
An infrastructure team configured a VNet in Azure with the default DNS server (Azure-provided DNS). After deploying a private DNS zone called internal.contoso.com and linking it to the VNet, the network VMs continue resolving names through the public zone, ignoring the private zone.
What is the most likely cause of this behavior?
A) The private DNS zone needs to be created in the same region as the VNet to work properly.
B) The virtual network link was created without enabling auto-registration, and records need to be added manually.
C) The virtual network link was created, but auto-registration or resolution via private zone only works when the VNet DNS points to a custom resolver, not to Azure's default DNS.
D) The private DNS zone internal.contoso.com conflicts with the VNet's default DNS suffix and Azure ignores private zones with custom domains.
Question 2 — Technical Scenario
An architect needs VMs in two different VNets, in distinct regions, to resolve names from the same private DNS zone (shared.internal). He applies the following configuration:
Private DNS zone: shared.internal
VNet-A Link: enabled, auto-registration: disabled
VNet-B Link: enabled, auto-registration: disabled
VMs in VNet-A resolve zone names correctly. VMs in VNet-B cannot resolve.
What is the most likely cause?
A) Private DNS zones do not support links with more than one VNet simultaneously.
B) Auto-registration needs to be enabled on all links for resolution to work in secondary VNets.
C) The VNet-B link was created, but VNet-B's DNS still points to Azure's default DNS, which does not forward queries to private zones linked to other VNets.
D) VNet-B's DNS is not configured to use Azure's recursive resolution servers (168.63.129.16), which are necessary to query private DNS zones.
Question 3 — True or False
An Azure private DNS zone can be linked to up to 1,000 VNets for name resolution, but auto-registration can only be enabled on a maximum of 1 VNet per zone.
True or False?
Question 4 — Technical Scenario
A company uses on-premises DNS servers to resolve internal names (corp.local) and needs VMs in Azure to also resolve these names. The team configures the VNet's custom DNS servers with the on-premises server IPs:
VNet DNS Servers:
- 10.0.0.4 (primary on-premises DNS)
- 10.0.0.5 (secondary on-premises DNS)
After configuration, VMs in Azure resolve corp.local correctly, but start failing to resolve Azure service names like storageaccount.blob.core.windows.net.
What is the most appropriate correction?
A) Add 168.63.129.16 as a tertiary DNS server in the VNet configuration, as Azure automatically queries it as fallback.
B) Configure the on-premises DNS servers to forward queries for *.core.windows.net to 168.63.129.16, and keep the custom servers in the VNet.
C) Remove the custom DNS servers from the VNet and use only Azure's default DNS, creating a private DNS zone for corp.local.
D) Add static A records for each Azure service endpoint in the on-premises DNS zone.
Question 5 — Multiple Choice
An administrator needs VMs in a VNet to automatically resolve their own hostnames via a private DNS zone, without creating records manually. He creates the vms.internal zone, links it to the VNet and enables auto-registration.
Which statement correctly describes the resulting behavior?
A) Azure creates A records for all VMs in the VNet immediately after the link is created, including existing VMs without dynamic IP.
B) Azure automatically creates and removes A records in the zone as VMs are provisioned and deprovisioned, using the hostname configured in the NIC.
C) Auto-registration creates A and PTR records for all VMs, but PTR records require a separate reverse lookup zone linked to the same VNet.
D) Auto-registration only works for VMs created after the link is enabled; pre-existing VMs need to be restarted to have their records created.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
The virtual network link with a private DNS zone does not, by itself, imply that VM records will be automatically added. Auto-registration is a separate functionality that, when enabled on the link, makes Azure dynamically register VM hostnames in the private zone. Without it, the zone may resolve manually added names, but VMs will not have entries created automatically.
Alternative C represents a common misconception: Azure's default DNS (resolved via 168.63.129.16) is fully capable of querying private zones linked to the VNet, without needing a custom resolver. Alternative D is technically false: private zones with custom domains like internal.contoso.com work normally and do not conflict with Azure's internal suffixes.
Answer Key — Question 2
Answer: D
For VMs in a VNet to query private DNS zones, the VNet's effective DNS server needs to be Azure's recursive resolver, accessible via 168.63.129.16. This resolver knows all private zone links associated with the VNet. If VNet-B has a custom DNS server that does not forward to 168.63.129.16, queries never reach Azure's resolution plane, and the linked private zone is ignored.
Alternative A is false: a private zone supports links with hundreds of VNets. Alternative B is false: auto-registration only controls automatic record creation, not resolution capability. Alternative C describes a valid problem scenario, but is technically incomplete: Azure's default DNS already uses 168.63.129.16 internally, making D the more precise and direct root cause.
Answer Key — Question 3
Answer: True
Azure supports up to 1,000 VNet links per private DNS zone for name resolution purposes. However, auto-registration is a restricted functionality: only 1 VNet per zone can have auto-registration enabled. This occurs because auto-registration implies the zone is the authoritative source for that VNet's hostnames, and allowing multiple VNets with auto-registration in the same zone would generate registration conflicts.
This limit is often underestimated by architects who try to centralize registration of multiple VNets in a single private zone and discover that only one of them can use auto-registration.
Answer Key — Question 4
Answer: B
When the VNet uses custom DNS servers (on-premises, in this case), all DNS resolution traffic from VMs is directed exclusively to them. The on-premises servers, by default, do not know how to resolve public names of Azure services like *.blob.core.windows.net, as they have no visibility to Azure's resolver (168.63.129.16).
The correct solution is to configure the on-premises DNS servers to forward queries for Azure domains to 168.63.129.16. This preserves resolution of corp.local on internal servers and delegates Azure services resolution to Azure's native resolver.
Alternative A is incorrect: adding 168.63.129.16 as tertiary in the VNet does not work as automatic fallback when primary servers are accessible but return NXDOMAIN. Alternative C eliminates corp.local resolution which is a business requirement. Alternative D is operationally unfeasible and does not scale.
Answer Key — Question 5
Answer: B
Auto-registration in Azure private DNS zones works as a lifecycle tied to VM provisioning: A records are created when the VM is started or has its NIC configured, and removed when the VM is deleted or the NIC is disassociated. The hostname used is the name configured in the VM's network interface (NIC).
Alternative A is false on two points: auto-registration does not create records for VMs with static IPs without restart, and does not act "immediately" retroactively for all existing VMs without any lifecycle event. Alternative C is false: Azure does not automatically create PTR records via auto-registration in private zones, this requires explicit configuration in reverse lookup zones. Alternative D is a half-truth used as a distractor: pre-existing VMs can have their records created without necessarily restarting, as long as an IP update event occurs on the NIC.