Welcome back fellow geek to part two of my series on DNS in Azure. In the first post I covered some core concepts behind the DNS offerings in Azure. One of the core concepts was the 188.8.131.52 virtual IP address which acts the communication point when Azure services within a VNet need to talk to Azure DNS resolver. If you’re unfamiliar with it, circle back and read that portion of the post. I also covered the basic DNS offering, Azure-provided DNS. For this post I’m going to cover the newly minted Azure Private DNS service.
As I covered my last post, Azure-provided DNS is a decent service if you’re doing some very basic proof-of-concept testing, but not much use beyond that. The limited capabilities around record types, scale challenges for BYODNS when requiring resolution across multiple VNets, and no reverse DNS support typically have required an enterprise BYODNS solution. This meant organizations were stuck purchasing expensive NVAs or rolling VMs running BIND or Windows DNS Server. Beyond the overhead of having to manage all aspects of the VM we’re all familiar with, it also brings along legacy request and change management processes. In most enterprises application owners have to submit requests to central IT to have DNS entries created or modified. This is counter to the goal of empowering application owners to be more agile.
Thankfully, Microsoft heard the cries of application owners and central IT and introduced Azure Private DNS into public preview back in early 2018. After a few iterations and improvements, the service officially went general availability just last month. The service addresses many of the gaps Azure-provided DNS has such as:
- Support for custom DNS namespaces
- Support for all common DNS record types such as A, MX, CNAME, PTR
- Support for reverse DNS
- Automatic lifecycle management of VM DNS records
- Resolution across multiple VNets
Before we jump into the weeds, we’ll first want to cover the basic concepts of the service. Azure Private DNS zones are an Azure resource under the namespace of /providers/Microsoft.Network/privateDnsZones/. Each DNS zone you want to create is represented as a separate resource. Zones created in one subscription can be consumed in another subscription as long as they’re within the same Azure AD tenant. VNets can resolve and register DNS records with the zones you create after you “link” the VNet to the zone. Each zone can be linked to multiple VNets for registration and resolution. On other hand, VNets can be linked to multiple zones for resolution but only one zone for registration. Once a zone is linked to the VNet, VMs within the VNet resolve and/or register DNS records for those zones through the 184.108.40.206 virtual IP.
I’ll quickly cover the reverse lookup zone capability that comes along with using the service. When a VNet is linked to a zone for registration there is reverse lookup zone created for the VNet. VMs created in subnets within that VNet will register a PTR record for its FQDN of the private zone as well as a PTR record for FQDN of internal.cloudapp.net zone. Take note that records in the reverse lookup zone will only be resolvable by VMs within that VNet when sent through the 220.127.116.11 virtual IP.
In the image below VNet1 is linked to an Azure Private Zone for both resolution and registration. VNet2 is registered to a different Azure Private Zone for both resolution and registration. Both VNets are configured to use Azure DNS servers. In this scenario, Server1 will be able to perform a reverse lookup for the IP address of Server2 because it is within the same VNet. However, Server3 will not be able to perform a reverse lookup for Server2 because it is in a different VNet.
In addition to PTR records, the VMs also register A records for the private zone and the Azure-provided DNS zone. There are a few things to note about the A records automatically created in the private zone:
- Each record has a property called isAutoRegistered which has a boolean value of true for any records created through the auto-registration process.
- Auto-registered records have an extremely short TTL of 10 seconds. If you have plans of performing DNS scavenging, take note of this and that these records are automatically deleted when the VM is deleted.
The Azure-provided DNS zone dynamically created for the VNet is still created even when linking an Azure Private DNS zone to a VNet. Additionally, if you try to resolve the IP address using a single label hostname, you’ll get back the A record for the Azure-provided DNS zone. This is by design and allows you to control the DNS suffix automatically appended by your VMs. It also means you need to use the FQDN in any application configuration to ensure the record is resolved correctly.
Let’s now look at resolution between two VNets. In this scenario we again have VNet1 and VNet2. VNet1 is linked for both registration and resolution to the Azure Private DNS Zone of app1zone.com. VNet2 is linked for just resolution to the app1zone.com. VMs in VNet2 are able to resolve queries for the fully-qualified domain name of VMs in VNet1 as illustrated in the diagram below.
Beyond the auto-registration of records, you can also manually create a variety of record types as I mentioned above. There isn’t anything special or different in the way Azure is handling these records. The only thing worth noting is the records have a standard 1 hour TTL.
There are two significant limitations in the service right now. One of those limitations is no support for query logging. Given how important DNS query logging data can be as data points to identifying threats in the environment, your organization may require this. If so, you’ll need to insert some BYODNS into the mix (I’ll cover that pattern next post). The other bigger and more critical limitation is the lack of support for conditional forwarding. As of today, you can’t create conditional forwarders for the service which will prevent you from forwarding queries from the 18.104.22.168 virtual IP to other DNS services you may have running for resolution of other resources such as on-premises resources. Again, the workaround here is BYODNS. Expect both of these limitations to be addressed in time as the service matures.
Azure Private DNS alone is a great service if your organization is completely in the cloud and has basic DNS resolution needs. Some patterns you could leverage here:
- Separate private DNS zone for each application – In this scenario you could grant your application owners full control of the zone letting them manage the records as they see fit. This would improve the application team’s agility while reducing operational burden on central IT.
- Separate private DNS zones for each environment (Dev/QA/Prod) – In this scenario you could avoid having to do any BYODNS if there are no dependencies on on-premises infrastructure. You also get full lifecycle management of VM records cutting back on operational overhead.
Summing up the service:
- Managed service where you don’t have to worry the managing the underlining infrastructure
- Scalability and availability are baked into the service
- Use of custom DNS namespaces
- VMs spread across multiple VNets can resolve each other’s addresses
- Reverse DNS is supported within a VNet
- Lifecycle of the VMs DNS records are automatically managed by the platform
- Applications could be assigned their own DNS zones and application owners delegated full control over that zone
- No support for conditional forwarders at this time
- No support for DNS query logging at this time
- No support for WINS or NETBIOS (although I call this a positive 🙂 )
In my next post I’ll cover how the service works with BYODNS and will discuss some neat patterns that are available when you take advantage of the service.