DNS in Azure, Part 8: The Resolution Decision Tree

Seven posts of theory. This one is the lookup table.

A VM in Azure asks for a name. Where does the answer come from - the internet, Azure DNS, a private DNS zone, a privatelink zone, or a DNS server sitting in a datacentre three hundred kilometres away? And what exactly do you have to configure to make that happen?

Answer three or four questions below and you get the architecture, the steps, and the mistakes to avoid.

• Part 1 - fundamentals and Azure-provided name resolution
• Part 2 - private DNS zones and virtual network links
• Part 3 - Azure DNS Private Resolver
• Part 4 - Private Link and Private Endpoints
• Part 5 - Private Endpoints and private DNS
• Part 6 - private DNS fallback to internet
• Part 7 - DNS security policies
• Part 8 (this post) - the resolution decision tree

The decision tree

The four questions behind it

Strip away the branches and the whole thing is four questions, asked in this order. Learning the order is more useful than memorising the outcomes.

1. Where is the client? In a virtual network, or outside one. This decides whether the platform resolver is even in the path.
2. What does the VNet's DNS servers setting say? Default means 168.63.129.16 and everything the platform can do. Custom means your servers own the answer and linked private zones are invisible unless you forward.
3. What kind of name is it? Public, Azure private, privatelink, or on-premises. Each has exactly one mechanism.
4. Who owns the record? You, Microsoft, or somebody else's tenant. This is the question that produces the NxDomainRedirect conversation.

Every path at a glance

The same tree, flattened, for when you already know where you are going.

The evaluation order, one more time

Every outcome above is a consequence of this sequence. When something resolves to the wrong address, walk it from the top and you will find the cause before you reach the bottom.

  Query from a VM
        │
        ▼
  ┌─────────────────────────────────────────────┐
  │ 1. VNet DNS servers = custom?               │──yes──▶ your servers answer.
  └─────────────────────────────────────────────┘         Azure is out of the loop.
        │ no (Default)
        ▼
  ┌─────────────────────────────────────────────┐
  │ 2. Linked private DNS zone matches?         │──yes──▶ answered from the zone
  └─────────────────────────────────────────────┘         (or NXDOMAIN, unless
        │ no                                               NxDomainRedirect)
        ▼
  ┌─────────────────────────────────────────────┐
  │ 3. Forwarding ruleset linked to this VNet?  │──match─▶ out via outbound endpoint
  └─────────────────────────────────────────────┘          longest suffix wins
        │ no match
        ▼
  ┌─────────────────────────────────────────────┐
  │ 4. Azure DNS recursive lookup               │──────▶ public answer
  └─────────────────────────────────────────────┘

Two rules worth repeating because they cause most incidents:

• Zones beat rules. A linked private zone for corp.internal always wins over a forwarding rule for corp.internal. The rule never fires.
• A wildcard rule does not catch everything. Microsoft's reserved namespaces always resolve through Azure DNS, by design.

Troubleshooting, in the order that finds it fastest

1. What is the VM actually using as a resolver? Get-DnsClientServerAddress or resolvectl status. If it disagrees with the VNet setting, the DHCP lease is stale.
2. Run dig or nslookup against 168.63.129.16 directly. If that works and the normal lookup does not, the problem is client-side.
3. Follow the CNAME chain. Does the public name redirect into privatelink? Does privatelink resolve to a private IP?
4. Is the zone name exactly the published one, and is it linked to this virtual network?
5. Is there more than one zone with that name in the tenant? Check with Resource Graph.
6. Is a private zone shadowing a forwarding rule for the same suffix?
7. Is the private endpoint connection Approved? Perfect DNS and a Pending connection look identical from the client.
8. Is there a route and a firewall opening for UDP and TCP 53, in both directions?
9. Are you near the 10,000 QPS ceiling on an endpoint? Check Azure Monitor metrics before your users tell you.
10. Turn on DNS query logging and stop guessing.

Closing the series

Eight posts, and it comes down to a handful of durable ideas:

• Every private query in a virtual network ends at 168.63.129.16, and the VNet's DNS servers setting decides who is asked first.
• A private DNS zone only exists for the virtual networks you explicitly link, and it always beats a forwarding rule.
• The DNS Private Resolver adds the two hybrid directions the platform cannot do alone, driven by rulesets with a documented evaluation order.
• A Private Endpoint is a NIC. It does not close the public door, and it does nothing for you until DNS points at it.
• The privatelink CNAME chain means on-premises forwarders target the public suffix.
• Fallback to internet fixes cross-tenant Private Link and quietly weakens your isolation story - choose it deliberately.
• DNS resolver policies finally give you logs and filtering without running a single VM.

If I had to compress all eight posts into one sentence: centralize DNS, and be able to draw the query path on a whiteboard. The architecture you can explain in thirty seconds is the one you will still be able to debug at 2 a.m.

Enjoy!