Azure DNS Private Resolver Usage — Verification with details 2/3
Recap of previous paper
Previous paper is here.
Next paper is here.
In our environment, we’ve configured a VNet to simulate an on-premise network, including a DNS server on a designated VM.
We verified successful DNS feature installation in Azure via RDP. Configure the on-premise network’s DNS server to match the Azure-promoted DNS server.
The continuation of the first paper
Step3:
In this step, our goal is illustrated in the following image especially focusing upon orange line.
Prerequisite
・Establish a VPN connection — follow here
・Create Hub VNet — 10.0.0.0/16
Within the Azure Portal, you can search for “Azure DNS Private Resolver” and proceed to configure both the inbound subnet and endpoint, as well as the outbound settings.
For this step, there’s no requirement to create an outbound endpoint and its rule set. Additionally, peering between the Hub and the Private Endpoint virtual network is not necessary to enable name resolution from an on-premise environment to a resource hosted within a Private Endpoint. It should function without these components.
However, it’s worth noting that both functionalities will be utilized in future work. Therefore, it is recommended to configure them in preparation for upcoming tasks.
The next setup is about Private endpoint.
In the Azure Portal, you have the option to search for “Storage accounts” and create them for various services that can support Private Endpoints. It’s important to ensure that the network setting for these storage accounts is set to “private,” indicating that you should create a Private Endpoint during the storage account deployment process.
In Private DNS zone, linking to hub and corresponding virtual network should be established as illustrated in the following image:
Let’s get back to the Client VM in On-premise VNet and open RDP connection.
From now on, we will add “Conditional Forwarder” in the DNS setting to resolve name of that storage account from on-premise client VM.
Firstly, we move to DNS setting from following list:
In “Conditional Forwarder” section, you can add DNS domain name and “IP Address of the master servers — this should be Azure DNS Private Resolver Inbound Endpoint” as illustrated in the following image:
Finally, you can run “nslookup” command:
The name resolution from the on-premise server has been successfully verified as you get a Address 10.2.0.4 which is Storage account private IP address.
2. “Enabling name resolution from a spoke client to an on-premise resource.”
In this section, our goal is to create this architecture:
Prerequisite
・Create Spoke VNet
・Create Client VM — Windows Server 2022, IP: 10.1.0.4
To enable the resolution of the on-premise resource’s name from the Spoke VM, it is necessary to establish a DNS forwarding rule within the outbound ruleset.
In the Azure Portal, you can initiate this process by searching for “DNS forwarding rulesets” and subsequently add a rule within the “Rule” section after the deployment of the ruleset is completed.
You should observe both the “Domain Name” and “Destination IP address” fields, and both should be pointing to the on-premise DNS server’s domain name and IP address.
As depicted in the image, it is essential to establish links to both the spoke and hub networks within the “DNS forwarding rulesets/Virtual network links” page.
Let’s get back to on-premise DNS server with RDP connection and open DNS Manger to register a new record for name resolution test as illustrated in the following image:
In the Spoke Client VM, open command prompt and run
nslookup onpreservice.contoso.localthis should returns the below result:
Great! Your spoke VM is now able to successfully resolve the name of the on-premise resource.
In the next which is final paper we are going to explore Azure Firewall forwarding and outbound traffic restriction as an alternative approach to utilizing the Azure DNS Private Resolver Inbound Endpoint.
