How can I configure DNS resolution to fall back to Azure Public DNS when a record is missing from the private zone?

Below is an explanation of the issue and available options:

---

Why It Happens

When you link a private DNS zone (in your case, test.com) to a VNET, any query from that VNET for names within test.com is answered using the linked private zone only. Even if a record (like external.test.com) exists in the public DNS zone, the private DNS zone takes precedence. If no matching record is found in the private zone, the query returns NXDOMAIN instead of “falling back” to check the public zone.

---

Is There a Fallback Mechanism?

Currently, Azure does not offer a native “fallback” resolution mechanism for a DNS zone that’s been overridden by a private DNS zone. In other words, you can’t configure Azure to say, “If a record isn’t present in the Private DNS Zone for test.com, then look it up in the Public DNS Zone.”

---

Azure DNS Private Resolver

Azure DNS Private Resolver is designed to help with conditional forwarding and hybrid name resolution scenarios. It introduces the ability to:

• Resolve names from both on-premises networks and Azure Private DNS zones
• Forward queries to custom DNS servers or to the public internet using outbound endpoints

However, even with the Private Resolver, the following holds true:

• The resolution order within the virtual network still gives priority to the private DNS zone.
• If a query for external.test.com is made from the VM, the private DNS zone is queried first.
• Since your private zone doesn’t contain an entry for external.test.com, the query fails.
• The Private Resolver does enable you to forward specific queries (using conditional forwarding rules) to an external DNS server, but the challenge is that the query is for a name within test.com. Once the private zone is linked to the VNET for the zone test.com, Azure DNS won’t “miss” the query; it uses the private zone exclusively for that zone namespace.

So, there isn’t a built-in way to configure a “fallback” for a subdomain of test.com from within the same zone.

---

Recommended Workarounds

1. Maintain Records in the Private Zone:
   The simplest workaround is to create the external.test.com A record in the Private DNS Zone. That ensures any queries from VNETs resolve correctly.

2. Split the Domain:
   Consider using separate domain names (or subdomains) for internal and external endpoints that do not overlap. For example, use internal.test.com for private resources and external.anotherdomain.com (or a different subdomain not managed by a private zone) for public records.

3. Custom DNS Forwarders:
   You might architect a custom DNS solution (for example, deploying your own DNS forwarder in the VNET) that conditionally forwards requests to public DNS servers if they aren’t handled locally. This is more complex and requires managing the resolution order manually.

4. Conditional Forwarding via Private Resolver (Limited):
   Although the Azure DNS Private Resolver can forward queries to an external DNS server, because the query’s suffix (test.com) is already associated with a private DNS zone, conditional forwarding rules would not engage for names within test.com unless you remove that association. For external.test.com, the private zone “short-circuits” the forwarding behavior.

---

Conclusion

At present, if you link a Private DNS Zone for test.com to your virtual network, any record lookups for test.com will only use that private zone. Azure does not offer a configuration where, for the same domain (test.com), the lookup falls back to the Public DNS Zone if a record isn’t found in the Private DNS Zone—even when using Azure DNS Private Resolver. If you require resolution of external.test.com from your VNET, you will need to add the record in the private zone or alter your domain architecture.

Feel free to ask if you need more details on any of these options.