dns topic

b-ahibbard · b-ahibbard · commit 7f15ded6ee52 · 2024-07-30T16:31:01.000-04:00
diff --git a/articles/azure-netapp-files/TOC.yml b/articles/azure-netapp-files/TOC.yml
@@ -45,6 +45,8 @@
         href: understand-data-encryption.md
       - name: Understand guidelines for Active Directory Domain Services
         href: understand-guidelines-active-directory-domain-service-site.md
+      - name: Understand DNS 
+        href: domain-name-system-concept.md
       - name: Understand the use of LDAP
         href: lightweight-directory-access-protocol.md
       - name: Understand NFS group memberships and supplemental groups
diff --git a/articles/azure-netapp-files/domain-name-system-concept.md b/articles/azure-netapp-files/domain-name-system-concept.md
@@ -8,7 +8,7 @@ ms.topic: how-to
 ms.date: 05/04/2023
 ms.author: anfdocs
 ---
-# Understand DNS requirements in Azure NetApp Files 
+# Understand Domain Name System in Azure NetApp Files 
 
 The Domain Name Systems (DNS) service is a critical component of data access in Azure NetApp Files when using file protocols that rely on Kerberos for authentication (including SMB and NFSv4.1). Not only does a hostname simplify access to a volume, it protects against scenarios when an IP address changes; instead of informing users of a new IP address, they can simply continue using the hostname. 
 
@@ -18,7 +18,7 @@ NFSv4.1 Kerberos operates in a similar manner for SPN retrieval, where DNS looku
 
 Azure NetApp Files supports the use of Active Directory integrated DNS or standalone DNS servers and requires reliable access to Domain Name System (DNS) services and up-to-date DNS records. Poor network connectivity between Azure NetApp Files and DNS servers can cause client access interruptions or client timeouts. Incomplete or incorrect DNS records for AD DS or Azure NetApp Files can cause client access interruptions or client timeouts. 
 
-## Using IP addresses for access with Kerberos 
+## IP addresses for access with Kerberos 
 
 If an IP address is used in an access request to an Azure NetApp Files volume, then a Kerberos request will operate differently depending on the protocol in use. 
 
@@ -31,41 +31,85 @@ When using NFSv4.1, a mount request to an IP address using one of the `sec=[krb5
 In Azure NetApp Files, DNS entries are created by: 
 
 <!-- "ate" -->
-- **An associated pointer (PTR) record” box is checked**: If reverse lookup zones for the subnet exist, then A/AAAA records automatically create PTR records without administrator intervention.
+- **An associated pointer (PTR) record box is checked**: If reverse lookup zones for the subnet exist, then A/AAAA records automatically create PTR records without administrator intervention.
 - **The “Delete this record when it becomes stale” box is checked.** When the DNS record becomes “stale,” DNS deletes the record, provided scavenging for DNS has been enabled.
 - **The DNS record’s “time to live (TTL)” is set to 1 day (24 hours)**. The TTL setting can be modified by the DNS administrator as needed. The TTL on a DNS record determines the length of time a DNS entry exists in a client’s DNS cache.
 
 >[!NOTE]
 >To view timestamps of when a DNS record was created in Windows Active Directory DNS, navigate to the **View** menu of the DNS Manager then select **Advanced**. 
 
-Azure NetApp Files volumes support dynamic DNS updates if the DNS server supports dynamic DNS. With dynamic DNS, volumes created with hostnames automatically notify the DNS server to create an A/AAAA record. If a reverse lookup zone exists, then DNS also creates a PTR record. If the reverse lookup zone doesn't exist, then a PTR record isn't created automatically, meaning you need to create it manually. Hostnames (rather than IP addresses) will be used for volume mount paths in specific configurations, which all require DNS for proper functionality:
-•	SMB volumes
-•	NFSv4.1 Kerberos
-•	Dual protocol volumes
-An IP address will be used when an Azure NetApp File volume does not require DNS, such as NFSv3 or NFSv4.1 without Kerberos. In those cases, if a DNS entry is desired, then it should be manually created.
-If a DNS entry created by dynamic DNS is deleted on the DNS server, it will be re-created within 24 hours by a new dynamic DNS update from Azure NetApp Files.
-When Azure NetApp Files creates a DNS A/AAAA record via dynamic DNS, the following configurations are used:
+Azure NetApp Files volumes support dynamic DNS updates if the DNS server supports dynamic DNS. With dynamic DNS, volumes created with hostnames automatically notify the DNS server to create an A/AAAA record. If a reverse lookup zone exists, then DNS also creates a PTR record. If the reverse lookup zone doesn't exist, then a PTR record isn't created automatically, meaning you need to create it manually.
 
+Hostnames (rather than IP addresses) are used for volume mount paths in specific configurations, which all require DNS for proper functionality:
 
-<!-- 
-### DNS requirements 
+- SMB volumes
+- NFSv4.1 Kerberos
+- Dual-protocol volumes
 
-Azure NetApp Files SMB, dual-protocol, and Kerberos NFSv4.1 volumes require reliable access to Domain Name System (DNS) services and up-to-date DNS records. Poor network connectivity between Azure NetApp Files and DNS servers can cause client access interruptions or client timeouts. Incomplete or incorrect DNS records for AD DS or Azure NetApp Files can cause client access interruptions or client timeouts.
+An IP address is used when an Azure NetApp File volume doesn't require DNS--such as NFSv3 or NFSv4.1 without Kerberos. In those cases, you can manually create a DNS entry if you desire. 
+
+If a DNS entry created by dynamic DNS is deleted on the DNS server, it's recreated within 24 hours by a new dynamic DNS update from Azure NetApp Files.
+
+<!-- When Azure NetApp Files creates a DNS A/AAAA record via dynamic DNS, the following configurations are used: -->
+
+## DNS record pruning/scavenging
+
+Most DNS servers provide methods to prune/scavenge expired records. Pruning helps prevent stale records from cluttering DNS servers and creating scenarios where duplicate A/AAAA and/or PTR records exist, which can create unpredictable outcomes for Azure NetApp Files volumes.
+
+If multiple PTR records for the same IP address point to different hostnames, Kerberos requests may fail because the incorrect SPN is being retrieved during DNS lookups. DNS doesn't discern which PTR record belongs to which hostname; instead, reverse lookups perform a round-robin search through each A/AAAA record for each new lookup. For example:
+
+```
+C:\> nslookup x.x.x.x
+Server:  contoso.com
+Address:  x.x.x.x
+
+Name:    ANF-1234.contoso.com
+Address:  x.x.x.x
+
+C:\> nslookup x.x.x.x
+Server:  contoso.com
+Address:  x.x.x.x
+
+Name:    ANF-5678.contoso.com
+Address:  x.x.x.x
+```
+
+## DNS aliases and Canonical Name (CNAME) records
+Azure NetApp Files creates a DNS hostname for a volume that has been configured for a protocol that requires DNS for proper functionality, such as SMB, dual protocol or NFSv4.1 with Kerberos. The name created is in the format of the SMB server (computer account) prefix name used when creating the Active Directory connection for the NetApp account with some extra alphanumeric characters to help uniquify multiple volume entries in the same NetApp account as needed. In most cases, multiple volumes that require hostnames and exist in the same NetApp account attempt to use the same hostnames/IP addresses. For example, if the SMB server name is SMB-West.contoso.com, then hostname entries follow the format of SMB-West-XXXX.contoso.com.
+
+In some cases, the name used by Azure NetApp Files may not be user-friendly enough to pass on to end users, or administrators may want to keep more familiar DNS names used when data has been migrated from on-premises storage to Azure NetApp Files (i.e., if the original DNS name was datalake.contoso.com, end users may want to continue using that name).
+
+Azure NetApp Files doesn't natively allow for the specification of DNS hostnames used. If you require an alternate DNS name with the same functionality, you should use a DNS alias/canonical name (CNAME).
+
+Using a CNAME record (rather than an additional A/AAAA record) that points to the Azure NetApp Files volume’s A/AAAA record leverages the same SPN as the SMB server to enable Kerberos access for both the A/AAAA record and CNAME. Consider the example of an A/AAAA record of SMB-West-XXXX.contoso.com. The CNAME record of datalake.contoso.com is configured to point back to A/AAAA record of SMB-West-XXXX.contoso.com. SMB or NFS Kerberos requests made to datalake.contoso.com use the Kerberos SPN for SMB-West-XXXX to provide access to the volume.
 
-Azure NetApp Files supports the use of [Active Directory integrated DNS](/windows-server/identity/ad-ds/plan/active-directory-integrated-dns-zones) or standalone DNS servers.    
+
+## DNS best practices in Azure NetApp Files
 
 Ensure that you meet the following requirements about the DNS configurations:
+
 * If you're using standalone DNS servers: 
     * Ensure that DNS servers have network connectivity to the Azure NetApp Files delegated subnet hosting the Azure NetApp Files volumes.
     * Ensure that network ports UDP 53 and TCP 53 are not blocked by firewalls or NSGs.
 * Ensure that [the SRV records registered by the AD DS Net Logon service](https://social.technet.microsoft.com/wiki/contents/articles/7608.srv-records-registered-by-net-logon.aspx) have been created on the DNS servers.
 * Ensure the PTR records for the AD DS domain controllers used by Azure NetApp Files have been created on the DNS servers in the same domain as your Azure NetApp Files configuration.
+* Azure NetApp Files supports standard and secure dynamic DNS updates. If you require secure dynamic DNS updates, ensure that secure updates are configured on the DNS servers.
+* If you're not using dynamic DNS updates, you need to manually create an A record and a PTR record for the AD DS computer account(s) created in the AD DS **Organizational Unit** (specified in the Azure NetApp Files AD connection) to support Azure NetApp Files LDAP Signing, LDAP over TLS, SMB, dual-protocol, or Kerberos NFSv4.1 volumes.
+* For complex or large AD DS topologies, [DNS Policies or DNS subnet prioritization may be required to support LDAP enabled NFS volumes](understand-guidelines-active-directory-domain-service-site.md#ad-ds-ldap-discover).  
+* If DNS scavenging is enabled (where stale DNS entries are automatically pruned based on timestamp/age) and dynamic DNS was used to create the DNS records for the Azure NetApp Files volume, the scavenger process might inadvertently prune the records for the volume. This pruning can lead to a service outage for name-based queries. Until this issue is resolved, manually create DNS A/AAAA and PTR entries for the Azure NetApp Files volume if DNS scavenging is enabled.
+
+
+<!-- 
+### DNS requirements 
+
+Azure NetApp Files SMB, dual-protocol, and Kerberos NFSv4.1 volumes require reliable access to Domain Name System (DNS) services and up-to-date DNS records. Poor network connectivity between Azure NetApp Files and DNS servers can cause client access interruptions or client timeouts. Incomplete or incorrect DNS records for AD DS or Azure NetApp Files can cause client access interruptions or client timeouts.
+
+Azure NetApp Files supports the use of [Active Directory integrated DNS](/windows-server/identity/ad-ds/plan/active-directory-integrated-dns-zones) or standalone DNS servers.    
+
+
 * Azure NetApp Files doesn’t automatically delete pointer records (PTR) associated with DNS entries when a volume is deleted. PTR records are used for reverse DNS lookups, which map IP addresses to hostnames. They are typically managed by the DNS server's administrator.
 When you create a volume in Azure NetApp Files, you can associate it with a DNS name. However, the management of DNS records, including PTR records, is outside the scope of Azure NetApp Files. Azure NetApp Files provides the option to associate a volume with a DNS name for easier access, but it doesn't manage the DNS records associated with that name. 
 If you delete a volume in Azure NetApp Files, the associated DNS records (such as the A records for forwarding DNS lookups) need to be managed and deleted from the DNS server or the DNS service you are using.
-* Azure NetApp Files supports standard and secure dynamic DNS updates. If you require secure dynamic DNS updates, ensure that secure updates are configured on the DNS servers.
-* If dynamic DNS updates are not used, you need to manually create an A record and a PTR record for the AD DS computer account(s) created in the AD DS **Organizational Unit** (specified in the Azure NetApp Files AD connection) to support Azure NetApp Files LDAP Signing, LDAP over TLS, SMB, dual-protocol, or Kerberos NFSv4.1 volumes.
-* For complex or large AD DS topologies, [DNS Policies or DNS subnet prioritization may be required to support LDAP enabled NFS volumes](#ad-ds-ldap-discover).  
-* If DNS scavenging is enabled (where stale DNS entries are automatically pruned based on timestamp/age) and dynamic DNS was used to create the DNS records for the Azure NetApp Files volume, the scavenger process might inadvertently prune the records for the volume. This pruning can lead to a service outage for name-based queries. Until this issue is resolved, manually create DNS A/AAAA and PTR entries for the Azure NetApp Files volume if DNS scavenging is enabled.
+
 
 -->
diff --git a/articles/azure-netapp-files/understand-guidelines-active-directory-domain-service-site.md b/articles/azure-netapp-files/understand-guidelines-active-directory-domain-service-site.md
@@ -62,25 +62,7 @@ The required network ports are as follows:
 
 \*\* LDAP over SSL (port 636) isn't currently supported. Instead, use [LDAP over StartTLS](configure-ldap-over-tls.md) (port 389) to encrypt LDAP traffic.
 
-### DNS requirements 
-
-Azure NetApp Files SMB, dual-protocol, and Kerberos NFSv4.1 volumes require reliable access to Domain Name System (DNS) services and up-to-date DNS records. Poor network connectivity between Azure NetApp Files and DNS servers can cause client access interruptions or client timeouts. Incomplete or incorrect DNS records for AD DS or Azure NetApp Files can cause client access interruptions or client timeouts.
-
-Azure NetApp Files supports the use of [Active Directory integrated DNS](/windows-server/identity/ad-ds/plan/active-directory-integrated-dns-zones) or standalone DNS servers.    
-
-Ensure that you meet the following requirements about the DNS configurations:
-* If you're using standalone DNS servers: 
-    * Ensure that DNS servers have network connectivity to the Azure NetApp Files delegated subnet hosting the Azure NetApp Files volumes.
-    * Ensure that network ports UDP 53 and TCP 53 are not blocked by firewalls or NSGs.
-* Ensure that [the SRV records registered by the AD DS Net Logon service](https://social.technet.microsoft.com/wiki/contents/articles/7608.srv-records-registered-by-net-logon.aspx) have been created on the DNS servers.
-* Ensure the PTR records for the AD DS domain controllers used by Azure NetApp Files have been created on the DNS servers in the same domain as your Azure NetApp Files configuration.
-* Azure NetApp Files doesn’t automatically delete pointer records (PTR) associated with DNS entries when a volume is deleted. PTR records are used for reverse DNS lookups, which map IP addresses to hostnames. They are typically managed by the DNS server's administrator.
-When you create a volume in Azure NetApp Files, you can associate it with a DNS name. However, the management of DNS records, including PTR records, is outside the scope of Azure NetApp Files. Azure NetApp Files provides the option to associate a volume with a DNS name for easier access, but it doesn't manage the DNS records associated with that name. 
-If you delete a volume in Azure NetApp Files, the associated DNS records (such as the A records for forwarding DNS lookups) need to be managed and deleted from the DNS server or the DNS service you are using.
-* Azure NetApp Files supports standard and secure dynamic DNS updates. If you require secure dynamic DNS updates, ensure that secure updates are configured on the DNS servers.
-* If dynamic DNS updates are not used, you need to manually create an A record and a PTR record for the AD DS computer account(s) created in the AD DS **Organizational Unit** (specified in the Azure NetApp Files AD connection) to support Azure NetApp Files LDAP Signing, LDAP over TLS, SMB, dual-protocol, or Kerberos NFSv4.1 volumes.
-* For complex or large AD DS topologies, [DNS Policies or DNS subnet prioritization may be required to support LDAP enabled NFS volumes](#ad-ds-ldap-discover).  
-* If DNS scavenging is enabled (where stale DNS entries are automatically pruned based on timestamp/age) and dynamic DNS was used to create the DNS records for the Azure NetApp Files volume, the scavenger process might inadvertently prune the records for the volume. This pruning can lead to a service outage for name-based queries. Until this issue is resolved, manually create DNS A/AAAA and PTR entries for the Azure NetApp Files volume if DNS scavenging is enabled.
+For information about DNS, see [Understand DNS in Azure NetApp Files](domain-name-system-concept.md). 
 
 ### Time source requirements 
 
@@ -238,3 +220,4 @@ Azure NetApp Files SMB, dual-protocol, and NFSv4.1 Kerberos volumes support cros
 * [Create a dual-protocol volume](create-volumes-dual-protocol.md)
 * [Errors for SMB and dual-protocol volumes](troubleshoot-volumes.md#errors-for-smb-and-dual-protocol-volumes)
 * [Access SMB volumes from Microsoft Entra joined Windows virtual machines](access-smb-volume-from-windows-client.md)
+* [Understand DNS in Azure NetApp Files](domain-name-system-concept.md). 
