Azure DNS Private Resolver Usage — Verification with details 3/3
Recap of previous paper
Before reading, please following 1st and 2nd paper.
We have achieved
1. “Facilitating name resolution from an on-premise environment to a resource hosted within a Private Endpoint.”
2. “Enabling name resolution from a spoke client to an on-premise resource.”
Therefore, we have now implemented the architecture as depicted in the following image:
To finalise and further enhance the utility of this architecture, we are now proceeding to exclusively utilise Azure Firewall for our networking needs.
3. “Exploring Azure Firewall forwarding and outbound traffic restriction as an alternative approach to utilizing the Azure DNS Private Resolver Inbound Endpoint.
In this section, you have the option to substitute the Azure DNS Private Resolver inbound endpoint with Azure Firewall DNS functionality. This approach can be particularly useful in scenarios where you aim to consolidate firewall capabilities within the Hub virtual network for simplified management and cost reduction.
By configuring the Firewall as a forwarder and additionally implementing an Azure Firewall policy to control outbound traffic for Azure MySQL with a Private Endpoint, while also using Azure Firewall as the DNS forwarder in the on-premise VM, you can achieve enhanced network security and control.
I followed「Microsoft Azure Well-Architected Framework」in this workload.
Attention
By configuring the Firewall as a forwarder, you can control outbound traffic for Azure MySQL with a Private Endpoint using an Azure Firewall policy. Additionally, using Azure Firewall as the DNS forwarder in the on-premise VM can enhance network security and control.
However, please note that there are specific configurations and considerations to be aware of when implementing this setup. For instance, Azure Firewall filters traffic using either FQDN in network rules for TCP and UDP protocols or FQDN in application rules for HTTP, HTTPS, and MSSQL. It’s recommended to use application rules over network rules when inspecting traffic destined to private endpoints in order to maintain flow symmetry.
Our goal architecture is illustrated in the following image:
I’ve highlighted the changes in red to make them easier to identify.
Prerequisites:
- Azure SQL: To conveniently monitor both inbound and outbound traffic. After creating the Azure Firewall resource
- AzureFirewallSubnet — 10.0.1.0/26
- IP: 10.0.14 You can configure Azure Firewall to act as a DNS forwarder using the settings illustrated in the following image:
To enable Private Endpoint VNet traffic to pass through Azure Firewall, you should attach a “User Defined Route” to the Gateway Subnet within the Hub VNet.
Now let’s move forward to set Azure Firewall Policy to control traffic.
In Application rule:
In the On-premise DNS server, we will change the master server to be Azure Firewall(10.0.1.4):
Then in Client VM in on-premise server, run the following command:
nslookup mysqlfordnstest.database.windows.netYou can make sure that a name resolution has successfuly completed:
Additionally, to verify the functionality of your Azure Firewall, you can utilise Log Analytics for monitoring purposes. In the Azure Firewall Diagnostic Setting, please ensure that you configure it according to the settings depicted in the following image:
Attention
Please ensure that the peering from the Private Endpoint VNet to the Hub allows for “Use remote virtual network gateway or route server.”
In the On-premise DNS server I used Microsoft SQL Server Management Studio to monitor the network traffic flow.
We have got a connection from Azure MySQL server via Azure Firewall.
To make sure this flow works as we expected, I open AzureFirewall/Logs to use Log Analytics:
By leveraging DNS within the Firewall, you can effectively route MySQL outbound traffic through the Firewall and collect Logs.
Wrap up
We have thoroughly examined the Azure DNS Private Resolver functionality and contemplated the possibility of substituting the inbound endpoint to optimise Azure resources in terms of cost and management efficiency. Additionally, we have successfully obtained logs from Azure Firewall to verify its role as a DNS forwarder and its effectiveness in restricting outbound traffic from private resources.
Thank you for taking the time to read this documentation. If you have any questions or require further clarification, I am here to assist you. Your feedback and suggestions are highly appreciated.
