Azure Custom DNS
-
I was looking at the Additional Configurations video in the Azure Virtual Desktop course and at 12 minutes 30 seconds it talks about using keeping the Azure DNS server as a secondary server to route to Azure resources but that doesn't seem to be accurate with how DNS works in Windows. The client only hits the primary server as long as it is online and if it doesn't have the record then it sends it to the forwarders configured in DNS. It looks like a DNS proxy is deployed in proxy and is used to forward the requests to in Azure based on the following Microsoft doc:
My question is what all would this be used for? Would it be used for faster connections to OneDrive/Teams/Sharepoint Online and is there a way to test this as far as seeing performance improvements before/after?
I see different things in the docs about it being used for machine learning, Azure SQL server, and Web Apps.We have a DC with DNS in Azure with a firewall using a site to site VPN to on prem. Our primary DNS setting in Azure is our DC in Azure and the secondary is our primary DNS server at our primary site.
-
Hello @Casey-Gorman ,
You are right, I should have added the Azure DNS server as a forwarder on the DNS server, not the client configuration.
In the diagram on the link you shared, 10.2.0.4 would be a VM that you created and installed DNS on. The VMs on vnet2 would be configured to use 10.2.0.4 for DNS.
Since vnet2 doesn't have a link to the on-premises network, it is configured to forward DNS requests for the domain and external names to 10.1.0.4. vnet1 has a site to site connection to the on-premises network, and 10.1.0.4 forwards the queries to the on-premises DNS server.
The on-premises DNS server is configured to use root hints to resolve external names. So this allows VMs to resolve domain names (because it's authoritative for that namespace) and external names.
If you need to connect to other VMs on the vnet that aren't part of the domain, or other Azure services, you will still need to use Azure DNS. For example, a VM on vnet2 that wasn't part of the domain would have a name like vm01.reddog.microsoft.com. To resolve that name, you need to connect to the Azure provided DNS 168.63.129.16. This is why we still need to forward some queries to that address. Some Azure service endpoints (like the ones you mentioned) are not resolvable publicly, and rely on the internal Azure DNS. Your private DNS server would not be authoritative for these, and not able to resolve those names.
I will add a note to that episode, until I can correct the demo.