|
| 1 | +--- |
| 2 | +title: Reliability in Azure DNS |
| 3 | +description: Learn about reliability in Azure DNS. |
| 4 | +author: anaharris-ms |
| 5 | +ms.author: anaharris |
| 6 | +ms.topic: overview |
| 7 | +ms.custom: subject-reliability, references-regions |
| 8 | +ms.service: traffic-manager |
| 9 | +ms.date: 02/02/2024 |
| 10 | +--- |
| 11 | + |
| 12 | + |
| 13 | +# Reliability in Azure DNS |
| 14 | + |
| 15 | +This article contains detailed information on [cross-region disaster recovery and business continuity](#cross-region-disaster-recovery-and-business-continuity) support for Azure DNS. |
| 16 | + |
| 17 | + |
| 18 | + |
| 19 | + |
| 20 | +## Cross-region disaster recovery and business continuity |
| 21 | + |
| 22 | +[!INCLUDE [introduction to disaster recovery](includes/reliability-disaster-recovery-description-include.md)] |
| 23 | + |
| 24 | + |
| 25 | +The Azure DNS failover solution for disaster recovery uses the standard DNS mechanism to fail over to the backup site. The manual option via Azure DNS works best when used in conjunction with the [cold standby or the pilot light approach](/azure/well-architected/reliability/highly-available-multi-region-design#active-passive). |
| 26 | + |
| 27 | +Since the DNS server is outside the failover or disaster zone, it's insulated against any downtime. You can architect a simple failover scenario as long as the operator has network connectivity during disaster and can make the flip. If the solution is scripted, then you must ensure that the server or service running the script is also insulated against the problem affecting the production environment. Also, a low TTL for the zone prevents resolver caching over long periods of time, allowing the customer to access the site within the RTO. For a cold standby and pilot light, since some prewarming and other administrative activity may be required, you should also give enough time before making the flip. |
| 28 | + |
| 29 | +>[!NOTE] |
| 30 | +>Azure private DNS zone supports DNS resolution between virtual networks across Azure regions, even without explicitly peering the virtual networks. However, all virtual networks must be linked to the private DNS zone. |
| 31 | +
|
| 32 | +To learn how to create an Azure private DNS zone using the Azure portal, see [Quickstart: Create an Azure private DNS zone using the Azure portal](/azure/dns/private-dns-getstarted-portal). |
| 33 | + |
| 34 | +To create an Azure DNS Private Resolver using Azure portal, see [Quickstart: Create an Azure DNS Private Resolver using the Azure portal](/azure/dns/dns-private-resolver-get-started-portal). |
| 35 | + |
| 36 | + |
| 37 | + |
| 38 | +## Disaster recovery in multi-region geography |
| 39 | + |
| 40 | +There are two technical aspects towards setting up your disaster recovery architecture: |
| 41 | + |
| 42 | +- Using a deployment mechanism to replicate instances, data, and configurations between primary and standby environments. This type of disaster recovery can be done natively viaAzure Site Recovery, see [Azure Site Recovery Documentation](../site-recovery/index.yml) via Microsoft Azure partner appliances/services like Veritas or NetApp. |
| 43 | + |
| 44 | +- Developing a solution to divert network/web traffic from the primary site to the standby site. This type of disaster recovery can be achieved via Azure DNS, [Azure Traffic Manager(DNS)](reliability-traffic-manager.md), or third-party global load balancers. |
| 45 | + |
| 46 | +This article focuses specifically on Azure DNS disaster recovery planning. |
| 47 | + |
| 48 | + |
| 49 | +#### Set up disaster recovery and outage detection |
| 50 | + |
| 51 | +The Azure DNS manual failover solution for disaster recovery uses the standard DNS mechanism to fail over to the backup site. The manual option via Azure DNS works best when used in conjunction with the cold standby or the pilot light approach. |
| 52 | + |
| 53 | + |
| 54 | + |
| 55 | +*Figure - Manual failover using Azure DNS* |
| 56 | + |
| 57 | +The assumptions made for the solution are: |
| 58 | +- Both primary and secondary endpoints have static IPs that don’t change often. Say for the primary site the IP is 100.168.124.44 and the IP for the secondary site is 100.168.124.43. |
| 59 | +- An Azure DNS zone exists for both the primary and secondary site. Say for the primary site the endpoint is prod.contoso.com and for the backup site is dr.contoso.com. A DNS record for the main application known as www\.contoso.com also exists. |
| 60 | +- The TTL is at or below the RTO SLA set in the organization. For example, if an enterprise sets the RTO of the application disaster response to be 60 mins, then the TTL should be less than 60 mins, preferably the lower the better. |
| 61 | + You can set up Azure DNS for manual failover as follows: |
| 62 | + - Create a DNS zone |
| 63 | + - Create DNS zone records |
| 64 | + - Update CNAME record |
| 65 | + |
| 66 | +1. Create a DNS zone (for example, www\.contoso.com) as shown below: |
| 67 | + |
| 68 | +  |
| 69 | + |
| 70 | + *Figure - Create a DNS zone in Azure* |
| 71 | + |
| 72 | +1. Within this zone, create three records (for example - www\.contoso.com, prod.contoso.com and dr.consoto.com) as show below. |
| 73 | + |
| 74 | +  |
| 75 | + |
| 76 | + *Figure - Create DNS zone records in Azure* |
| 77 | + |
| 78 | + In this scenario, site, www\.contoso.com has a TTL of 30 mins, which is well below the stated RTO, and is pointing to the production site prod.contoso.com. This configuration is during normal business operations. The TTL of prod.contoso.com and dr.contoso.com has been set to 300 seconds or 5 mins. |
| 79 | + You can use an Azure monitoring service such as Azure Monitor or Azure App Insights, or, any partner monitoring solutions such as Dynatrace. You can even use home grown solutions that can monitor or detect application or virtual infrastructure level failures. |
| 80 | + |
| 81 | +1. Once failure is detected, change the record value to point to dr.contoso.com as shown below: |
| 82 | + |
| 83 | +  |
| 84 | + |
| 85 | + *Figure - Update the CNAME record in Azure* |
| 86 | + |
| 87 | + Within 30 minutes, during which most resolvers will refresh the cached zone file, any query to www\.contoso.com will be redirected to dr.contoso.com. |
| 88 | + You can also run the following Azure CLI command to change the CNAME value: |
| 89 | + ```azurecli |
| 90 | + az network dns record-set cname set-record \ |
| 91 | + --resource-group 123 \ |
| 92 | + --zone-name contoso.com \ |
| 93 | + --record-set-name www \ |
| 94 | + --cname dr.contoso.com |
| 95 | + ``` |
| 96 | + This step can be executed manually or via automation. It can be done manually via the console or by the Azure CLI. The Azure SDK and API can be used to automate the CNAME update so that no manual intervention is required. Automation can be built via Azure functions or within a third-party monitoring application or even from on-premises. |
| 97 | +
|
| 98 | +
|
| 99 | +## Next steps |
| 100 | +
|
| 101 | +- [Reliability in Azure](/azure/reliability/availability-zones-overview) |
| 102 | +- Learn more about [Azure Traffic Manager](../traffic-manager/traffic-manager-overview.md). |
| 103 | +- Learn more about [Azure DNS](../dns/dns-overview.md). |
0 commit comments