Use Azure cloud native DNS resolver for split horizon

It’s time for the Azure Spring Clean again this year! This wonderful event brings together many Azure content creators to share their work. So check out the website for many more interesting pieces of content!

Over the last few events I’ve been telling about Azure DNS and I want to continue this story. If you want you can check out the earlier posts I made about that:

• Use traffic analytics to spot common azure network mistakes

• Using DNS in Azure IaaS

• How to use a cloud native DNS resolver in Azure

So this time I want to tell more about the Azure Cloud Native Private DNS resolver. Last time I wrote about how to use this to improve your hybrid environment. This time I want to look at a different use case for this tool.

Time to clean our DNS!

Many times I’ve been in environments where they had a problem. They created an internal domain which was publicly routable. For example the domain was called autosysops.com. Machines get names in this domain and can be found easily. But once they start to host (web)apps which need to be accessible from both inside the network as from the outside the problems start to arise.

This is a situation which is called a split brain or split horizon DNS. Imagine in this environment a webserver was hosted to present the website www.autosysops.com. Users on the internal network will have the autosysops.com zone internally on the DNS server so it will be resolved there. Users on the internet will go to a public DNS server and from there be forwarded to the public version of the autosysops.com domain server. In most cases it’s not recommended to have the internal DNS server open to the internet, as this can be used to inventory your internal network.

View fullsize

There are now two places the record could be for internal users. So in most cases the solution I see for this problem is:

View fullsize

Admins will create the records in the public zone (which is often hosted at a different company) and make sure the records are up to date with the internal store. When having different routes to the resource for public and private users this can be a nice solution as it allows for the different routes. But more and more often a web app doesn’t mean just a server somewhere, it’s an intricate collection of services like a web application firewall, api manager and several different compute units (like containers or functions). So often both internal and external users need to end up at the same endpoint anyways to make sure the whole application can be controlled properly and secure.

To make this easier to manage the Azure Private DNS resolver can be used. When deployed you can create DNS forwarding rules.

View fullsize

These rules allow the private resolver to send the queries to the right place. In the screenshot above you see a rule for DEMO and DEMO2. These are both on-premise DNS servers which are connected to an AD DS domain. With a rule like this all DNS queries for these domains will be send to the respective DNS server.

But what if these domains host a web app? This is shown in the rules for SITE-DEMO and SITE-DEMO2. These are webservers hosting a web app in this specific domain. But these web apps are also available to be accessed from the internet. In this example you’ll see that the destination IP is set to 8.8.8.8 which is the google public DNS server. This is done so from there it will use the public DNS hierarchy to find the right public DNS server. It could be pointed directly to the DNS server but if things change this way it will always work. Due to caching adding an extra server in the chain doesn’t slow down the process except when not entry is in the cache.

By using a set up like this the record can be placed in the public DNS zone and in the private resolver only this forwarder is needed. This will prevent the situation where the location of a web app is changed and DNS records are needing to be updated in both the private and public DNS stores at the same time. Especially when working with different suppliers or partners this often ends up with down time to some users not being able to access the application.

If you want to be able to manage your DNS even better you should consider using an Azure Public DNS Zone.

View fullsize

By using a public DNS zone in Azure you can manage the public DNS yourself instead of having to rely on a third party. The Azure public DNS is high available and easy to configure. One of the big advantages is that you can manage it using Infrastructure as Code (IaC). This allows you to have the DNS records being updated on deployment of the resources in Azure.

These is also something called an alias record which can be used in a public DNS zone. These are not to be confused with CNAME records. These alias records are records to specific azure resources. You can point it to the resource and the Azure DNS will update the record if the IP address changes. For example when using a non static IP address for a public resource this way it will be up to date in your public DNS at any time.

By combining the Private DNS resolver and the Azure Public DNS Zones you can create a DNS infrastructure which will always be up to date and allows for a more Agile way of work with fast deployments. I hope this information has helped you and will convince you to start cleaning up the DNS infrastructure!