review of scearios and wording

Author: mblanco77

articles/private-link/media/private-endpoint-dns/hybridscenario.png

@@ -10,19 +10,24 @@ ms.author: allensu
 ---
 # Azure Private Endpoint DNS Configuration
 
-## DNS configuration 
+
 When connecting to a private link resource using a fully qualified domain name (FQDN) as part of the connection string, it's important to correctly configure your DNS settings to resolve to the allocated private IP address. Existing Azure services might already have a DNS configuration to use when connecting over a public endpoint. This needs to be overridden to connect using your private endpoint. 
 
 The network interface associated with the private endpoint contains the complete set of information required to configure your DNS, including FQDN and private IP addresses allocated for a given private link resource. 
 
 You can use the following options to configure your DNS settings for private endpoints: 
 - **Use the Host file (only recommended for testing)**. You can use the host file on a virtual machine to override the DNS.  
-- **Use a private DNS zone**. You can use private DNS zones to override the DNS resolution for a given private endpoint. A private DNS zone can be linked to your virtual network to resolve specific domains.
+- **Use a private DNS zone**. You can use [private DNS zones](../dns/private-dns-privatednszone.md) to override the DNS resolution for a given private endpoint. A private DNS zone can be linked to your virtual network to resolve specific domains.
 - **Use your custom DNS server**. You can use your own DNS server to override the DNS resolution for a given private link resource. If your [DNS server](../virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances.md#name-resolution-that-uses-your-own-dns-server) is hosted on a virtual network, you can create a DNS forwarding rule to use a private DNS zone to simplify the configuration for all private link resources.
 
 > [!IMPORTANT]
 > It's not recommended to override a zone that is actively in use to resolve public endpoints. Connections to resources won't be able to resolve correctly without DNS forwarding to the public DNS. To avoid issues, create a different domain name or follow the suggested name for each service below. 
+
+## Azure services DNS zone configuration
+Azure services will create a canonical name DNS record (CNAME) on the public DNS to redirect the resolution to the suggested private domain names. You'll be able to override the resolution with the private IP address of your private endpoints. 
 
+Your applications don't need to change the connection URL. When attempting to resolve using a public DNS, the DNS server will now resolve to your private endpoints. The process does not impact your existing applications. 
+
 For Azure services, use the recommended zone names as described in the following table:
 
 |Private Link resource type   |Subresource  |Zone name  |
@@ -57,71 +62,72 @@ For Azure services, use the recommended zone names as described in the following
 |Azure WebApps (Microsoft.Web/sites)    | site | privatelink.azurewebsites.net |
 |Azure Machine Learning(Microsoft.MachineLearningServices/workspaces)    | workspace | privatelink.api.azureml.ms |
 
-Azure will create a canonical name DNS record (CNAME) on the public DNS to redirect the resolution to the suggested domain names. You'll be able to override the resolution with the private IP address of your private endpoints. 
- 
-Your applications don't need to change the connection URL. When attempting to resolve using a public DNS, the DNS server will now resolve to your private endpoints. The process does not impact your applications. 
 
-## DNS integration scenarios
 
-DNS is a critical component to make private endpoints work correctly within a solution.
-These scenarios are oriented to guide you on how to get the dns resolution integrated based where the clients are located 
+## DNS configuration scenarios
 
-### cloud only scenarios
- > [!NOTE]
-> These scenarios use Azure SQL database as the integrated private endpoint, still the guidance applies to any other Azure service that has an integrated the private endpoint.
+The FQDN of the services resolves a public ip address, you have to change your DNS configuration to resolve the private IP address of the private endpoint.
 
+DNS is a critical component to make the application work correctly by resolving in a right manner the private endpoint IP address.
 
-- Single VNET and Azure Provided DNS
+Based on your preferences the following scenarios will guide you on how to get the DNS resolution integrated
 
-This an Azure only scenario where the client queries for the private endpoint IP to Azure provided DNS [168.63.129.16](https://docs.microsoft.com/azure/virtual-network/what-is-ip-address-168-63-129-16) that makes the authoritative resolution and then queries the azure private dns zone for the required record.
+- [Virtual Network workloads without custom DNS server](#Virtual-Network-workloads-without-custom-DNS-server)
+- [On Premise forwarding DNS to Azure](#On-Premise-forwarding-DNS-to-Azure)
 
+## Virtual Network workloads without custom DNS server
 
-![single vnet and azure provided dns](media/private-endpoint-dns/single-vnet-azure-dns.png)
+This configuration is appropriate for virtual network workloads without custom DNS server, in this scenario the client queries for the private endpoint IP address to Azure provided DNS [168.63.129.16](https://docs.microsoft.com/azure/virtual-network/what-is-ip-address-168-63-129-16). Azure DNS will be responsible for DNS resolution of the private DNS zones.
 
-- Hub and Spoke with Azure provided DNS
 
-In this scenario there's a [hub & spoke](https://docs.microsoft.com/azure/architecture/reference-architectures/hybrid-networking/hub-spoke) networking topology with the spoke networks sharing a common private endpoint and all the spoke VNET are linked to the same private dns zone. 
+ > [!NOTE]
+> This scenario is using Azure SQL database recommended Private DNS zone. For other services you can adjust the model using the following reference [Azure services DNS zone configuration](#Azure-services-DNS-zone-configuration).
 
-![hub & spoke with azure provided dns](media/private-endpoint-dns/hubandspoke-azure-dns.png)
+To configure properly you would need the following resources :
 
+- client virtual network
 
+- private dns zones [(privatelink.database.windows.net)](../dns/private-dns-privatednszone.md)  with [A Record](../dns/dns-zones-records#record-types)
 
-### on premise scenario
+- private endpoint information (FQDN record name and Private IP Address)
 
- > [!NOTE]
-> This scenario use Azure SQL database as the integrated private endpoint, still the guidance applies to any other Azure service that has an integrated the private endpoint.
+The following diagram illustrates the DNS resolution sequence from virtual network workloads using private dns zone
 
-- on premise forwarding to Azure
 
-This scenario corresponds to an on premise network that has its internal dns solution (10.0.0.254) that forwards dns traffic via a conditional forwarder for the general zone database.windows.net and chains up the dns resolution to the custom dns (10.5.0.254) deployed in Azure.
+![single vnet and azure provided dns](media/private-endpoint-dns/single-vnet-azure-dns.png)
 
- > [!NOTE]
-> The internal DNS (10.0.0.254) is applicable only if there is an existing dns solution in place , or else the clients can use directly the custom DNS deployed in Azure (10.5.0.254)
 
-> [!IMPORTANT]
-> The conditional forwarding must be made to the original zone Ex: database.windows.net , NOT **privatelink**.database.windows.net
+This model can be extended to multiple VNet peered that are associated to the same private endpoint. this can be done by adding new links to the private DNS zone for all peered VNets
 
+ > [!IMPORTANT]
+>  A single private DNS zone is required for this configuration, creating multiple zones with the same name for different VNets would need manual operations to merge the DNS records
 
-![On-prem forward to azure](media/private-endpoint-dns/onpremdns-forward-to-azure.png)
+In this scenario there's a [hub & spoke](https://docs.microsoft.com/azure/architecture/reference-architectures/hybrid-networking/hub-spoke) networking topology with the spoke networks sharing a common private endpoint and all the spoke VNet are linked to the same private dns zone. 
 
+![hub & spoke with azure provided dns](media/private-endpoint-dns/hubandspoke-azure-dns.png)
 
-### hybrid scenario
- > [!NOTE]
-> This scenario use Azure SQL database as the integrated private endpoint, still the guidance applies to any other Azure service that has an integrated the private endpoint.
 
-This scenario shows:
+## On Premise forwarding DNS to Azure
 
-- on-premise network that has its internal dns solution (10.0.0.254) that forwards dns traffic via a conditional forwarder for the general zone database.windows.net and chains up the dns resolution to the custom dns (10.5.0.254) deployed in Azure.
+This configuration is appropriate for an on premise network that has already an internal dns solution. 
+This internal DNS solution needs to be configured to forward DNS traffic to Azure via a conditional forwarder.
 
-- spoke vnet (vnet-spoke-eastus-001) sharing a private link endpoint and private dns zone
+ > [!NOTE]
+> This scenario is using Azure SQL database recommended Private DNS zone. For other services you can adjust the model using the following reference [Azure services DNS zone configuration](#Azure-services-DNS-zone-configuration).
+
+To configure properly you would need the following resources :
 
-> [!NOTE]
-> The internal DNS (10.0.0.254) is applicable only if there is an existing dns solution in place , or else the clients can use directly the custom DNS deployed in Azure (10.5.0.254)
+- on premise network with a DNS solution in place 
+- client virtual network
+- private dns zones [(privatelink.database.windows.net)](../dns/private-dns-privatednszone.md)  with [A Record](../dns/dns-zones-records#record-types)
+- private endpoint information (FQDN record name and Private IP Address)
+
+The following diagram illustrates the DNS resolution sequence from virtual network workloads using private dns zone
 
 > [!IMPORTANT]
-> The conditional forwarding must be made to the original zone Ex: database.windows.net , NOT **privatelink**.database.windows.net
+> The conditional forwarding must be made to the base DNS zone Ex: database.windows.net , NOT **privatelink**.database.windows.net
 
+![On-prem forward to azure](media/private-endpoint-dns/onpremdns-forward-to-azure.png)
 
-![hybrid scenario](media/private-endpoint-dns/hybridscenario.png)
 
 

articles/private-link/private-endpoint-dns.md

@@ -101,7 +101,9 @@ When connecting to a private link resource using a fully qualified domain name (
 
 The network interface associated with the private endpoint contains the complete set of information required to configure your DNS, including FQDN and private IP addresses allocated for a given private link resource. 
 
-please review [integrate dns with private endpoints](private-endpoint-dns.md) for more details.
+For complete detailed information about best practices and recommendations to configure DNS for Private Endpoints, please review [Private Endpoint DNS configuration article](private-endpoint-dns.md).
+
+
 
 
 ## Limitations