Merge pull request #229832 from greg-lindsay/dns-design

Dns design

Author: prmerger-automator[bot]

articles/dns/private-resolver-architecture.md

@@ -35,9 +35,9 @@ Consider the following hub and spoke VNet topology in Azure with a private resol
         - The DNS forwarding ruleset is linked to the spoke VNet.
         - A ruleset rule is configured to forward queries for the private zone to the inbound endpoint.
 
-**DNS resolution in the hub VNet**: The virtual network link from the private zone to the Hub VNet enables resources inside the hub VNet to automatically resolve DNS records in **azure.contoso.com** using Azure-provided DNS ([168.63.129.16](../virtual-network/what-is-ip-address-168-63-129-16.md)). All other namespaces are also resolved using Azure-provided DNS. The hub VNet doesn't use ruleset rules to resolve DNS names because it is not linked to the ruleset. To use forwarding rules in the hub VNet, create and link another ruleset to the Hub VNet.
+**DNS resolution in the hub VNet**: The virtual network link from the private zone to the Hub VNet enables resources inside the hub VNet to automatically resolve DNS records in **azure.contoso.com** using Azure-provided DNS ([168.63.129.16](../virtual-network/what-is-ip-address-168-63-129-16.md)). All other namespaces are also resolved using Azure-provided DNS. The hub VNet doesn't use ruleset rules to resolve DNS names because it isn't linked to the ruleset. To use forwarding rules in the hub VNet, create and link another ruleset to the Hub VNet.
 
-**DNS resolution in the spoke VNet**: The virtual network link from the ruleset to the spoke VNet enables the spoke VNet to resolve **azure.contoso.com** using the configured forwarding rule. A link from the private zone to the spoke VNet is not required here. The spoke VNet sends queries for **azure.contoso.com** to the hub's inbound endpoint. Other namespaces are also resolved for the spoke VNet using the linked ruleset if rules for those names are configured in a rule. DNS queries that don't match a ruleset rule use Azure-provided DNS. 
+**DNS resolution in the spoke VNet**: The virtual network link from the ruleset to the spoke VNet enables the spoke VNet to resolve **azure.contoso.com** using the configured forwarding rule. A link from the private zone to the spoke VNet isn't required here. The spoke VNet sends queries for **azure.contoso.com** to the hub's inbound endpoint. Other namespaces are also resolved for the spoke VNet using the linked ruleset if rules for those names are configured in a rule. DNS queries that don't match a ruleset rule use Azure-provided DNS. 
 
 > [!IMPORTANT]
 > In this example configuration, the hub VNet must be linked to the private zone, but must **not** be linked to a forwarding ruleset with an inbound endpoint forwarding rule. Linking a forwarding ruleset that contains a rule with the inbound endpoint as a destination to the same VNet where the inbound endpoint is provisioned can cause DNS resolution loops.
@@ -64,7 +64,7 @@ Consider the following hub and spoke VNet topology with an inbound endpoint prov
 **DNS resolution in the spoke VNet**: In this example, the spoke VNet sends all of its DNS traffic to the inbound endpoint in the Hub VNet. Since **azure.contoso.com** has a virtual network link to the Hub VNet, all resources in the Hub can resolve **azure.contoso.com**, including the inbound endpoint (10.10.0.4). Thus, the spoke uses the hub inbound endpoint to resolve the private zone. Other DNS names are resolved for the spoke VNet according to rules provisioned in a forwarding ruleset, if they exist.
 
 > [!NOTE]
-> In the centralized DNS architecture scenario, both the hub and the spoke VNets can use the optional hub-linked ruleset  when resolving DNS names. This is because all DNS traffic from the spoke VNet is being sent to the hub due to the VNet's custom DNS setting. The hub VNet doesn't require an outbound endpoint or ruleset here, but if one is provisioned and linked to the hub (as shown in Figure 2), both the hub and spoke VNets will use the forwarding rules. As mentioned previously, it is important that a forwarding rule for the private zone is not present in the ruleset because this configuration can cause a DNS resolution loop.
+> In the centralized DNS architecture scenario, both the hub and the spoke VNets can use the optional hub-linked ruleset  when resolving DNS names. This is because all DNS traffic from the spoke VNet is being sent to the hub due to the VNet's custom DNS setting. The hub VNet doesn't require an outbound endpoint or ruleset here, but if one is provisioned and linked to the hub (as shown in Figure 2), both the hub and spoke VNets will use the forwarding rules. As mentioned previously, it is important that a forwarding rule for the private zone isn't present in the ruleset because this configuration can cause a DNS resolution loop.
 
 ## Next steps