Specific guidance on DNS and Azure network architecture

Question

Hi MS Support,

Could you please advice us on the following diagram:

Current Implementation:
Currently we have set up Virtual Network to use DNS Server which we have set it to be the private IP address of the Azure Firewall. This means all DNS queries will be forwarded to the Azure Firewall, the Azure Firewall has a DNS proxy set up to Inbound Private DNS Resolver. The Inbound Private DNS Resolver is within a hub extension virtual network that stores all of the current Private DNS Zone (Private DNS Zone linking is to the hub extension virtual network)

Suggested Solution from Internal support:
To prevent unauthorized VNets from resolving googleapis.com, there is another option of creating private DNS zones and attaching them to specific VNet.

Private DNS Zone Scoping

• Restrict the googleapis.com Private DNS Zone attachment to only the selected Databricks VNets.

• Ensure that no other VNets are linked to the Private DNS Zone.

Would the above suggested solution work? Noting that we keep the virtual network to use the DNS Server to resolve other private dns zones such as storage account.

Problem Statement:

1. If other VNET in the future require storage.googleapis.com to resolve different (e.g. Public) endpoints from Google, how will that be resolved if we were to use the current DNS set up in the hub extension virtual network?
2. Where will the entries be placed for resolution to same endpoint storage.googleapis.com?
3. While a firewall can restrict access to resources from unauthorised VNets, does it prevent DNS resolution?
4. If other VNets can resolve googleapis.com, unintended traffic may traverse the associated Private Service Connection, potentially leading to security risks or performance concerns. Is Azure Firewall restriction such as Deny rule suffice to prevent other VNet to resolve googlesapis.com?

Answer 1

Hello Colin Loh (Admin - Versent)

Greetings!

Azure Private DNS to enable fallback to internet recursion when an authoritative NXDOMAIN response is received for a Private Link zone. NXDOMAIN is also known as a negative response. When a DNS resolver receives (or has cached) a negative response, it sends no DNS response to the DNS client and the query fails.

Check the reference doc:

https://learn.microsoft.com/en-us/azure/dns/private-dns-fallback

You can configure Azure Firewall to act as a DNS proxy. A DNS proxy is an intermediary for DNS requests from client virtual machines to a DNS server.

If you want to enable FQDN (fully qualified domain name) filtering in network rules, enable DNS proxy and update the virtual machine configuration to use the firewall as a DNS proxy.

DNS proxy configuration using a custom DNS server.

If you enable FQDN filtering in network rules, and you don't configure client virtual machines to use the firewall as a DNS proxy, then DNS requests from these clients might travel to a DNS server at a different time or return a different response compared to that of the firewall. It’s recommended to configure client virtual machines to use the Azure Firewall as their DNS proxy. This puts Azure Firewall in the path of the client requests to avoid inconsistency.

Check the reference doc:

https://learn.microsoft.com/en-us/azure/firewall/fqdn-filtering-network-rules

Suggestions:

• You can use Firewall Application Rules to explicitly deny traffic for (googleapis.com) based on specific source VNets.
• If you want to resolve this (googleapis.com) over public endpoints in the future, you can create a UDR on the source VNets/subnets to direct the traffic over the internet gateway as the next hop instead of the Azure firewall private IP. This way, only specific destination IPs can go over the internet, but the issue is that we need to mention the IP instead of the domain name.

---

Hope the above answer helps! Please let us know do you have any further queries.

Please do consider to “up-vote” wherever the information provided helps you, this can be beneficial to other community members.