This is a continuation of a series of articles on operational engineering aspects of Azure public cloud computing that included the most recent discussion on Azure Data Lake which is a full-fledged general availability service that provides similar Service Level Agreements as expected from others in the category. This article focuses on Azure DNS.  This is a hosting service for DNS domains that provides name resolution by using Microsoft Azure infrastructure. This lets us manage DNS records, but it is not something to buy a domain name with. For that, App Service domain works well. When the domains are available, they can be hosted in the Azure DNS for records management.

While Azure DNS has many features including activity logs, resource locking and Azure RBAC, the DNSSEC is not supported because HTTP/TLS is available instead. If it is required, then DNS zones can be hosted with third party DNS hosting providers.

The DNS records help with name resolution of services and resources.  It can manage DNS records for external services as well. It supports private DNS domains as well which allows us to use custom domain names with private virtual networks.

It supports record sets where we can use an alias record that is set to refer to an Azure resource. If the IP address of the underlying resource changes, the alias record set updates itself during DNS resolution. 

Each resource must be given a name. With records in the domain name server, the resource becomes reachable and resolvable from a virtual network. The following options are available to configure the DNS settings for a resource: 1) using only the host file that resolves the name locally 2) using a private DNS zone to override the DNS resolution for a private endpoint with the zone linked to the virtual network, and 3) using a DNS forwarder with a rule to use the DNS Zone in another DNS server. It is preferrable to not override a zone that resolves public endpoints because if the connectivity to the public DNS goes down, those public endpoints will remain unreachable. That is why a different domain name with a suffix such as “core.windows.net” is recommended. Multiple zones with the same name for different virtual networks would need manual operations to merge the DNS records.

A common problem with traditional DNS records is dangling records. The DNS records that haven’t been updated to reflect changes to IP addresses are called dangling records. With a traditional DNS zone record, the target IP or CNAME no longer exists. It requires manual updates which can be costly. A delay in updating DNS records can potentially cause an extended outage for the users. Alias records avoid this situation by tightly coupling the lifecycle of a DNS record with an Azure resource.

The DNS protocol prevents the assignment of a CNAME records at the zone apex. This restriction presents a problem when there are load balanced applications behind a Traffic Manager whose profile requires the creation of a CNAME record. This can be mitigated with Alias records which can be creaeted at the zone apex.