Merge pull request #212541 from greg-lindsay/dns-upd

Reliability article for private resolver

Author: Stacyrch140

articles/dns/TOC.yml

@@ -105,6 +105,8 @@
     items:
     - name: Endpoints and rulesets
       href: private-resolver-endpoints-rulesets.md
+    - name: Resiliency in Azure DNS Private Resolver
+      href: private-resolver-reliability.md
 - name: How-to guides
   items:
   - name: Public DNS

articles/dns/dns-alerts-metrics.md

@@ -3,14 +3,14 @@ title: Metrics and alerts - Azure DNS
 description: With this learning path, get started with Azure DNS metrics and alerts.
 services: dns
 documentationcenter: na
-author: rohinkoul
+author: greg-lindsay
 manager: kumudD
 ms.service: dns
 ms.topic: article
 ms.tgt_pltfrm: na
 ms.workload: infrastructure-services
-ms.date: 04/26/2021
-ms.author: rohink
+ms.date: 09/27/2022
+ms.author: greglin
 ---
 
 # Azure DNS metrics and alerts
@@ -30,7 +30,7 @@ Azure DNS provides the following metrics to Azure Monitor for your DNS zones:
 For more information, see [metrics definition](../azure-monitor/essentials/metrics-supported.md#microsoftnetworkdnszones).
 
 >[!NOTE]
-> At this time, these metrics are only available for Public DNS zones hosted in Azure DNS. If you have Private Zones hosted in Azure DNS, these metrics will not provide data for those zones. In addition, the metrics and alerting feature is only supported in Azure Public cloud. Support for sovereign clouds will follow at a later time. 
+> At this time, these metrics are only available for Public DNS zones hosted in Azure DNS. If you have Private Zones hosted in Azure DNS, these metrics won't provide data for those zones. In addition, the metrics and alerting feature is only supported in Azure Public cloud. Support for sovereign clouds will follow at a later time. 
 
 The most granular element that you can see metrics for is a DNS zone. You currently can't see metrics for individual resource records within a zone.
 
@@ -70,14 +70,14 @@ To view this metric, select **Metrics** explorer experience from the **Monitor**
 
 ## Alerts in Azure DNS
 
-Azure Monitor has alerting that you can configure for each available metric values. See [Azure Monitor alerts](../azure-monitor/alerts/alerts-metric.md) for more information.
+Azure Monitor has alerting that you can configure for each available metric value. See [Azure Monitor alerts](../azure-monitor/alerts/alerts-metric.md) for more information.
 
 1. To configure alerting for Azure DNS zones, select **Alerts** from *Monitor* page in the Azure portal. Then select **+ New alert rule**.
 
     :::image type="content" source="./media/dns-alerts-metrics/alert-metrics.png" alt-text="Screenshot of Alert button on Monitor page.":::
 
 
-1. Click the **Select resource** link in the Scope section to open the *Select a resource* page. Filter by **DNS zones** and then select the Azure DNS zone you want as the target resource. Select **Done** once you have choose the zone.
+1. Click the **Select resource** link in the Scope section to open the *Select a resource* page. Filter by **DNS zones** and then select the Azure DNS zone you want as the target resource. Select **Done** once you've chosen the zone.
 
     :::image type="content" source="./media/dns-alerts-metrics/select-resource.png" alt-text="Screenshot of select resource page in configuring alerts.":::
 

articles/dns/dns-faq-private.yml

@@ -96,12 +96,12 @@ sections:
       - question: |
           Why don’t my existing private DNS zones show up in new portal experience?
         answer: |
-          If your existing private DNS zone were created using preview API, you must migrate these zones to new resource model. Private DNS zones created using preview API will not show up in new portal experience. See below for instructions on how to migrate to new resource model.
+          If your existing private DNS zone were created using preview API, you must migrate these zones to new resource model. Private DNS zones created using preview API won't show up in new portal experience. See below for instructions on how to migrate to new resource model.
 
       - question: |
           How do I migrate my existing private DNS zones to the new model?
         answer: |
-          We strongly recommend that you migrate to the new resource model as soon as possible. Legacy resource model will be supported, however, further features will not be developed on top of this model. In future, we intend to deprecate it in favor of new resource model. For guidance on how to migrate your existing private DNS zones to new resource model see[migration guide for Azure DNS private zones](private-dns-migration-guide.md).
+          We strongly recommend that you migrate to the new resource model as soon as possible. Legacy resource model will be supported, however, further features won't be developed on top of this model. In future, we intend to deprecate it in favor of new resource model. For guidance on how to migrate your existing private DNS zones to new resource model see[migration guide for Azure DNS private zones](private-dns-migration-guide.md).
           
           ### Does Azure DNS private zones store any customer content?
           No, Azure DNS private zones doesn't store any customer content.

articles/dns/dns-getstarted-portal.md

@@ -16,7 +16,7 @@ ms.custom: mode-ui
 
 You can configure Azure DNS to resolve host names in your public domain. For example, if you purchased the *contoso.xyz* domain name from a domain name registrar, you can configure Azure DNS to host the *contoso.xyz* domain and resolve *`www.contoso.xyz`* to the IP address of your web server or web app.
 
-In this quickstart, you will create a test domain, and then create an address record to resolve *www* to the IP address *10.10.10.10*.
+In this quickstart, you'll create a test domain, and then create an address record to resolve *www* to the IP address *10.10.10.10*.
 
 :::image type="content" source="media/dns-getstarted-portal/environment-diagram.png" alt-text="Diagram of DNS deployment environment using the Azure portal." border="false":::
 

articles/dns/dns-private-resolver-get-started-portal.md

@@ -95,7 +95,7 @@ Next, add a virtual network to the resource group that you created, and configur
 
     ![create resolver - review](./media/dns-resolver-getstarted-portal/resolver-review.png)
 
-    After selecting **Create**, the new DNS resolver will begin deployment. This process might take a minute or two, and you'll see the status of each component as it is deployed.
+    After selecting **Create**, the new DNS resolver will begin deployment. This process might take a minute or two, and you'll see the status of each component as it's deployed.
 
     ![create resolver - status](./media/dns-resolver-getstarted-portal/resolver-status.png)
 

articles/dns/dns-reverse-dns-overview.md

@@ -32,7 +32,7 @@ For example, the DNS record `www.contoso.com` is implemented using a DNS 'A' rec
 When an organization is assigned an IP address block, they also acquire the right to manage the corresponding ARPA zone. The ARPA zones corresponding to the IP address blocks used by Azure are hosted and managed by Microsoft. Your ISP may host the ARPA zone for you for the IP addresses you owned. They may also allow you to host the ARPA zone in a DNS service of your choice, such as Azure DNS.
 
 > [!NOTE]
-> Forward DNS lookups and reverse DNS lookups are implemented in separate, parallel DNS hierarchies. The reverse lookup for 'www.contoso.com' is **not** hosted in the zone 'contoso.com', rather it is hosted in the ARPA zone for the corresponding IP address block. Separate zones are used for IPv4 and IPv6 address blocks.
+> Forward DNS lookups and reverse DNS lookups are implemented in separate, parallel DNS hierarchies. The reverse lookup for 'www.contoso.com' is **not** hosted in the zone 'contoso.com', rather it's hosted in the ARPA zone for the corresponding IP address block. Separate zones are used for IPv4 and IPv6 address blocks.
 
 ### IPv4
 

articles/dns/private-dns-import-export.md

@@ -46,13 +46,13 @@ Importing a zone file creates a new zone in Azure private DNS if one does not al
 
 The following notes provide additional technical details about the zone import process.
 
-* The `$TTL` directive is optional, and it is supported. When no `$TTL` directive is given, records without an explicit TTL are imported set to a default TTL of 3600 seconds. When two records in the same record set specify different TTLs, the lower value is used.
-* The `$ORIGIN` directive is optional, and it is supported. When no `$ORIGIN` is set, the default value used is the zone name as specified on the command line (plus the terminating ".").
+* The `$TTL` directive is optional, and it's supported. When no `$TTL` directive is given, records without an explicit TTL are imported set to a default TTL of 3600 seconds. When two records in the same record set specify different TTLs, the lower value is used.
+* The `$ORIGIN` directive is optional, and it's supported. When no `$ORIGIN` is set, the default value used is the zone name as specified on the command line (plus the terminating ".").
 * The `$INCLUDE` and `$GENERATE` directives are not supported.
 * These record types are supported: A, AAAA, CAA, CNAME, MX, NS, SOA, SRV, and TXT.
 * The SOA record is created automatically by Azure DNS when a zone is created. When you import a zone file, all SOA parameters are taken from the zone file *except* the `host` parameter. This parameter uses the value provided by Azure DNS. This is because this parameter must refer to the primary name server provided by Azure DNS.
 * The name server record set at the zone apex is also created automatically by Azure DNS when the zone is created. Only the TTL of this record set is imported. These records contain the name server names provided by Azure DNS. The record data is not overwritten by the values contained in the imported zone file.
-* During Public Preview, Azure DNS supports only single-string TXT records. Multistring TXT records are be concatenated and truncated to 255 characters.
+* During Public Preview, Azure DNS supports only single-string TXT records. Multistring TXT records will be concatenated and truncated to 255 characters.
 
 ### CLI format and values
 
@@ -68,7 +68,7 @@ Values:
 * `<zone name>` is the name of the zone.
 * `<zone file name>` is the path/name of the zone file to be imported.
 
-If a zone with this name does not exist in the resource group, it is created for you. If the zone already exists, the imported record sets are merged with existing record sets.
+If a zone with this name does not exist in the resource group, it's created for you. If the zone already exists, the imported record sets are merged with existing record sets.
 
 ### Import a zone file
 
@@ -80,7 +80,7 @@ To import a zone file for the zone **contoso.com**.
     az group create --resource-group myresourcegroup -l westeurope
     ```
 
-2. To import the zone **contoso.com** from the file **contoso.com.txt** into a new DNS zone in the resource group **myresourcegroup**, you will run the command `az network private-dns zone import`.<BR>This command loads the zone file and parses it. The command executes a series of commands on the Azure DNS service to create the zone and all the record sets in the zone. The command reports progress in the console window, along with any errors or warnings. Because record sets are created in series, it may take a few minutes to import a large zone file.
+2. To import the zone **contoso.com** from the file **contoso.com.txt** into a new DNS zone in the resource group **myresourcegroup**, you'll run the command `az network private-dns zone import`.<BR>This command loads the zone file and parses it. The command executes a series of commands on the Azure DNS service to create the zone and all the record sets in the zone. The command reports progress in the console window, along with any errors or warnings. Because record sets are created in series, it may take a few minutes to import a large zone file.
 
     ```azurecli
     az network private-dns zone import -g myresourcegroup -n contoso.com -f contoso.com.txt

articles/dns/private-resolver-reliability.md

@@ -0,0 +1,59 @@
+---
+title: Resiliency in Azure DNS Private Resolver #Required; Must be "Resiliency in *your official service name*"
+description: Find out about reliability in Azure DNS Private Resolver #Required; 
+author: greg-lindsay #Required; your GitHub user alias, with correct capitalization.
+ms.author: greglin #Required; Microsoft alias of author; optional team alias.
+ms.custom: subject-reliability
+ms.service: dns
+ms.topic: conceptual
+ms.date: 09/27/2022 #Required; mm/dd/yyyy format.
+#Customer intent: As a customer, I want to understand reliability support for Azure DNS Private Resolver. I need to avoid failures and respond to them so that I can minimize down time and data loss.
+---
+
+# Resiliency in Azure DNS Private Resolver
+
+This article describes reliability support in Azure DNS Private Resolver, and covers both regional resiliency with [availability zones](#availability-zones) and cross-region resiliency with disaster recovery. 
+
+> [!NOTE]
+> Azure DNS Private Resolver supports availability zones without any further configuration! When the service is provisioned, it's deployed across the different availability zones, and will provide zone resiliency out of the box.
+
+For a comprehensive overview of reliability in Azure, see [Azure reliability](/azure/architecture/framework/resiliency/overview).
+
+## Azure DNS Private Resolver
+
+[Azure DNS Private Resolver](dns-private-resolver-overview.md) enables you to query Azure DNS private zones from an on-premises environment, and vice versa, without deploying VM based DNS servers. You no longer need to provision IaaS based solutions on your virtual networks to resolve names registered on Azure private DNS zones. You can configure conditional forwarding of domains back to on-premises, multicloud, and public DNS servers. 
+
+## Availability zones
+
+For more information about availability zones, see [Regions and availability zones](/azure/availability-zones/az-overview).
+
+### Prerequisites
+
+For a list of regions that support availability zones, see [Azure regions with availability zones](/azure/availability-zones/az-region#azure-regions-with-availability-zones). If your Azure DNS Private Resolver is located in one of the regions listed, you don't need to take any other action beyond provisioning the service.
+
+#### Enabling availability zones with private resolver
+
+To enable AZ support for Azure DNS Private Resolver, you do not need to take further steps beyond provisioning the service. Just create the private resolver in the region with AZ support, and it will be available across all AZs.
+
+For detailed steps on how to provision the service, see [Create an Azure private DNS Resolver using the Azure portal](dns-private-resolver-get-started-portal.md).
+
+### Fault tolerance
+
+During a zone-wide outage, no action is required during zone recovery. The service will self-heal and rebalance to take advantage of the healthy zone automatically. The service is provisioned across all the AZs. 
+
+## Disaster recovery and cross-region failover
+
+For cross-region failover in Azure DNS Private Resolver, see [Set up DNS failover using private resolvers](tutorial-dns-private-resolver-failover.md).
+
+In the event of a regional outage, use the same design as that described in [Set up DNS failover using private resolvers](tutorial-dns-private-resolver-failover.md). When you configure this failover design, you can keep resolving names using the other active regions, and also increase the resiliency of your workloads. 
+
+All instances of Azure DNS Private Resolver run as Active-Active within the same region.
+
+The service health is onboarded to [Azure Resource Health](/azure/service-health/resource-health-overview), so you'll be able to check for health notifications when you subscribe to them. For more information, see [Create activity log alerts on service notifications using the Azure portal](/azure/service-health/alerts-activity-log-service-notifications-portal).
+
+Also see the [SLA for Azure DNS](https://azure.microsoft.com/support/legal/sla/dns/v1_1/).
+
+## Next steps
+
+> [!div class="nextstepaction"]
+> [Resiliency in Azure](/azure/availability-zones/overview)

articles/dns/tutorial-dns-private-resolver-failover.md

@@ -5,14 +5,14 @@ services: dns
 author: greg-lindsay
 ms.service: dns
 ms.topic: tutorial
-ms.date: 08/18/2022
+ms.date: 09/27/2022
 ms.author: greglin
 #Customer intent: As an administrator, I want to avoid having a single point of failure for DNS resolution.
 ---
 
 # Tutorial: Set up DNS failover using private resolvers
 
-This article details how to eliminate a single point of failure in your on-premises DNS services by using two or more Azure DNS private resolvers deployed across different regions. DNS failover is enabled by assigning a local resolver as your primary DNS and the resolver in an adjacent region as secondary DNS. 
+This article details how to eliminate a single point of failure in your on-premises DNS services by using two or more Azure DNS private resolvers deployed across different regions. DNS failover is enabled by assigning a local resolver as your primary DNS and the resolver in an adjacent region as secondary DNS. If the primary DNS server fails to respond, DNS clients automatically retry using the secondary DNS server.
 
 > [!IMPORTANT]
 > Azure DNS Private Resolver is currently in [public preview](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).