Happy Holidays! It’s time for the #festivetechcalendar2023. This wonderful event hosted by the cloudfamily is a yearly event which features many different content creators in the IT space. This blogpost will be my contribution this year. Check back every day during the month of December to see new content being released and don’t forget to support the charity if you enjoy all this content.

Santa's cloud native naughty or nice list

To stay in theme the case which will be looked at will be that of Santa Claus. Say you want to create a system to check if someone was naughty or nice but you want to distribute this system over different parts so not everything needs to be maintained centrally. In this case a system like DNS can be used. DNS stands for Domain Name System and is used on the internet for many different applications. One of the ways it’s used is to make sure users can enter a human readable address for a website instead of the IP address. The DNS system will read this provided URL and transform it to an IP address.

This DNS system is build to be scalable and many networks will contain servers or devices handling some DNS tasks. It is possible that in a simple network you are only using DNS servers which are hosted on the internet. But if you want to add to this system too and make sure internal resources can be resolved using the same system you need your own infrastructure.

In the case of Santa a system can be set up with several windows servers all hosting different DNS Zones. These zones allow for the children to be split in different groups for example split by region so it’s easier to maintain and different helpers can be used for the different regions. It’s important that client devices which are used to query the data are setup to use the internal DNS servers. It’s also important that the servers are aware of each other so that the different zones are known and can be queried. If the requested data isn’t available in any of the zones hosted internally the DNS servers will do a recursive lookup online to get this information.

This online lookup works in a hierarchical way. But for now let’s look at a different scenario. Like many organizations eventually Santa wanted to migrate some infrastructure to the cloud and decided to use the Microsoft Azure cloud.

When using Azure many network related matters will be hosted by Azure. In a previous blogpost I wrote about how DNS in Azure works already. The important part here is that the IP address 168.63.129.16 is used internally to resolve any DNS queries which go to Azure related resources. In many situations the DNS queries for azure resources are stored in a private DNS zone. This resources can be seen a a serverless DNS server which can host a DNS zone. This is often used when PaaS resources in Azure are connected to the virtual network and get their own network adapter and therefore and IP address on the network. To reach these resources on the same name they would have be reached publicly the private DNS zone is used to resolve this.

But often not only the Azure resources need to be resolved but also the resources hosted on own DNS servers. In the case of Santa they need to be able to query the Azure resources to keep the environment running but they also need to be able to query the other DNS servers now hosted in the cloud for the list of naughty and nice children. To do this a DNS forwarder is configured. When using the Azure Edition of Windows Server this forwarder will be configured by default.

If an organization only works in the Azure this setup will work. It’s important to make sure the clients are configured to use the self hosted DNS servers which will use the forwarder to send any traffic they can’t resolve to Azure which will make sure it’s then resolved. But often when doing a migration to Azure not all old infrastructure is removed. Often a hybrid scenario is created where still some resources live on-premises or in a datacenter. These other locations can be connected to Azure by using a VPN or Express Route. But issues start to occur in the design of the DNS environment once this is set up. When someone from the on-premises environment needs to resolve a resource in the private DNS zone in Azure and the DNS servers are configured in the same way something weird will happen.

The IP address for the Azure DNS resolver is an public IP address. So either in the configuration of the VPN/Express Route this specific IP address needs to be configured to be send to Azure or the resolve won’t work.

To solve this issue the go to solution was to use conditional forwarders on-premises. This way all the zones which are defined in the private DNS zones need to be listed on the on-premise server and be forwarded to a DNS server living in the cloud which then can use the configured forwarder to actually resolve the address.

This scenario works but it requires a lot of manual configuration as every time a new Zone is introduced in Azure this needs to be added as a conditional forwarder on-premises. Also every resource in Azure needs to be configured to use the self hosted DNS servers to make sure everything can be resolved. When using some PaaS resources this will require more complex configurations too.

So to solve this issue not so long ago Microsoft release the cloud native DNS resolver. This resolver effectively allows for configuration of the azure DNS server. It allows admins to configure (conditional) forwarders in the Azure DNS it self. It also provides a private IP address which can be used from on-premises as a forwarder instead of having to configure conditional forwarders.

When using resources in Azure the cloud native DNS resolver removes the need to configure the DNS server to a specific IP address. Resources can query the Azure DNS which will recognize a cloud native DNS resolver is configured and forward the queries there. In the resolver rules can be defined to have queries for specific domains to go specific places. For example queries for the naughty or nice list can still be send to the self hosted DNS servers while other queries will be handles by azure itself.

It’s also possible to configure the IP address of the resolver directly onto machines, that way the step to the Azure DNS is skipped.
When working on-premises this is what is used. Instead of having the conditional forwarder now all traffic not known is forwarded to the IP address of the private DNS resolver.

The cloud native DNS resolver will be used to either query a self hosted DNS server in Azure or if it doesn’t contain a rule it will check if a Private DNS zone is linked to it’s virtual network and if so it can resolve this too.

This way allows for a less complex configuration and less management of the different zones. There is still some configuration to do as every self hosted domain in the azure environment needs to be entered into the resolver. The advantage here is that these can be configured using infrastructure as code which allows you to automate the process.

In a next blogpost I will talk about how this cloud native DNS resolver can also be used to handle a split-brain DNS setup. For now I want to wish everyone happy holidays and don’t forget to check out the other content for the Festive Tech Calendar too!