resolve warnings

Author: b-ahibbard

articles/azure-netapp-files/domain-name-system-concept.md

@@ -10,7 +10,7 @@ ms.author: anfdocs
 ---
 # Understand Domain Name Systems in Azure NetApp Files 
 
-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 Active Directory Domain Services (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 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 time outs. Incomplete or incorrect DNS records for Active Directory Domain Services (AD DS) or Azure NetApp Files can cause client access interruptions or client time outs. 
 
 The DNS service is a critical component of data access in Azure NetApp Files. File protocol access over SMB, NFSV4.1 Kerberos, LDAP, and Active Directory Site Discovery all make significant use of DNS for their operations. Using a hostname centrally located in DNS simplifies access to a volume and protects against scenarios when an IP address changes. Rather than an administrator needing to inform users of a new IP address, users can continue using the user-friendly hostname.
 
@@ -31,7 +31,7 @@ In some cases, external DNS servers (such as BIND) may be used in lieu of (or in
 
 :::image type="content" source="media/domain-name-system-concept/external-bind-dns.png" alt-text="Diagram of external bind configuration." lightbox="media/domain-name-system-concept/external-bind-dns.png":::
 
-Azure NetApp Files supports the use of both integrated and external DNS servers, but when using external DNS servers without Active Directory integration, it is important to ensure that the necessary service (SRV) records are added to DNS for proper functionality and redundancy of services. 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 both integrated and external DNS servers, but when using external DNS servers without Active Directory integration, it's important to ensure that the necessary service (SRV) records are added to DNS for proper functionality and redundancy of services. Poor network connectivity between Azure NetApp Files and DNS servers can cause client access interruptions or client time outs. Incomplete or incorrect DNS records for AD DS or Azure NetApp Files can cause client access interruptions or client time outs.
 
 See [DNS records in Azure NetApp Files](#types-of-dns-records-in-azure-netapp-files) for a list of SRV records the service uses. Also review the [guidelines for DNS with Active Directory](/windows-server/) and [Integrating AD DS into an existing DNS infrastructure](/windows-server/identity/ad-ds/plan/integrating-ad-ds-into-an-existing-dns-infrastructure).
 
@@ -65,7 +65,7 @@ Azure NetApp Files makes use of different types of DNS records for access to fil
 | -- | ------- |
 | A/AAAA | DNS [A records](https://www.cloudflare.com/learning/dns/dns-records/dns-a-record/) are address records that indicate the IPv4 address for a hostname. AAAA records indicate the IPv6 address for a hostname. Azure NetApp Files uses [A/AAAA records](https://www.cloudflare.com/learning/dns/dns-records/dns-aaaa-record/) in the following ways: <ul><li>Masking IP addresses behind user-friendly hostnames</li><li>Kerberos service principal requests</li><li>Root domain queries</li></ul> |
 | Pointer records (PTR) | A [PTR record](https://www.cloudflare.com/learning/dns/dns-records/dns-ptr-record/) maps an IP address to a hostname by way of a reverse [lookup zone](https://developers.cloudflare.com/dns/additional-options/reverse-zones/). PTR records are primarily used when an IP address is specified for a mount/share in Azure NetApp Files. Use of an IP address in mount/share requests can impact the authentication method used. For more information, see [IP addresses for access with Kerberos](kerberos.md#ip-addresses-for-access-with-kerberos).
-| Service records (SRV)	| [SRV records](https://www.cloudflare.com/learning/dns/dns-records/dns-srv-record/) are used to specify which hosts and ports are used for a specific service, such as LDAP, NFS, CIFS, Kerberos, etc. SRV records in Azure NetApp Files are heavily utilized for file service security (such as Kerberos), site discovery in Active Directory, LDAP server queries, and more. It's important to verify the existence of these records for proper functionality of Azure NetApp Files services. <br></br> SRV records can be queried using `nslookup` or `dig` commands. For examples, see [Using nslookup and dig for DNS queries](#using-nslookup-and-dig-for-dns-queries). |
+| Service records (SRV)	| [SRV records](https://www.cloudflare.com/learning/dns/dns-records/dns-srv-record/) are used to specify which hosts and ports are used for a specific service, such as LDAP, NFS, CIFS, Kerberos, etc. SRV records in Azure NetApp Files are heavily utilized for file service security (such as Kerberos), site discovery in Active Directory, LDAP server queries, and more. It's important to verify the existence of these records for proper functionality of Azure NetApp Files services. <br></br> SRV records can be queried using `nslookup` or `dig` commands. For examples, see [Using `nslookup` and `dig` for DNS queries](#using-nslookup-and-dig-for-dns-queries). |
 | Canonical names (CNAME) | A CNAME record is a way to provide DNS aliases for A/AAAA records. CNAME records are optional but can be useful to reduce the complexity of the hostname records provided by Azure NetApp Files. For more information, see [DNS aliases and Canonical Name records](#dns-aliases-and-canonical-name-cname-records). |
 | Uniform Resource Identifier (URI) | A [URI record](https://www.rfc-editor.org/rfc/rfc7553) is a way to map hostnames/IP addresses for services to URIs. URIs are presented in a format as such: service://fqdn.contoso.com. <br></br> Azure NetApp Files makes use of queries for URI records only when performing Kerberos KDC lookups for NFS Kerberos requests. URI records aren't created in Active Directory DNS deployments by default. As such, URI lookup requests usually fail and fall back to SRV record lookups. |
 
@@ -321,11 +321,11 @@ When secure DNS is enabled, Azure NetApp Files negotiates with the DNS server to
 
 To reduce load on DNS servers, DNS clients make use of caching concepts to store previous queries in memory so that repeat requests for a hostname, IP or service are kept locally for the period of time defined by the DNS record’s TTL.
 
-Azure NetApp Files makes use of DNS caches like any other standard DNS client. When the service requests a DNS record, that record has a TTL defined. By default, Active Directory DNS entries have a TTL of 600 seconds (10 minutes) unless specified otherwise. If a DNS record is updated and lives in the Azure NetApp Files cache and the TTL is 10 minutes, then the new record doesn't update in Azure NetApp Files until the cache is purged after the timeout value. There is currently no way to manually purge this cache. If a lower TTL is desired, make the change from the DNS server.
+Azure NetApp Files makes use of DNS caches like any other standard DNS client. When the service requests a DNS record, that record has a TTL defined. By default, Active Directory DNS entries have a TTL of 600 seconds (10 minutes) unless specified otherwise. If a DNS record is updated and lives in the Azure NetApp Files cache and the TTL is 10 minutes, then the new record doesn't update in Azure NetApp Files until the cache is purged after the time out value. There's currently no way to manually purge this cache. If a lower TTL is desired, make the change from the DNS server.
 
-When using external DNS servers (such as BIND), the default timeout values can differ. If undefined, a BIND DNS record's TTL is 604,800 seconds (seven days), too long for effective DNS caching. As such, when creating DNS records manually, it is important to manually set the TTL for the record to a reasonable value. Using the Microsoft default of 10 minutes is recommended for a blend of performance and reliability for DNS lookups.
+When using external DNS servers (such as BIND), the default time out values can differ. If undefined, a BIND DNS record's TTL is 604,800 seconds (seven days), too long for effective DNS caching. As such, when creating DNS records manually, it is important to manually set the TTL for the record to a reasonable value. Using the Microsoft default of 10 minutes is recommended for a blend of performance and reliability for DNS lookups.
 
-You can manually query a DNS record's TTL using `nslookup` or `dig` commands. For examples, see [Using nslookup and dig for DNS queries](#using-nslookup-and-dig-for-dns-queries).
+You can manually query a DNS record's TTL using `nslookup` or `dig` commands. For examples, see [Using `nslookup` and `dig` for DNS queries](#using-nslookup-and-dig-for-dns-queries).
 
 ## DNS record pruning/scavenging
 
@@ -363,7 +363,7 @@ Using a CNAME record (rather than an additional A/AAAA record) that points to th
 
 ## Using nslookup and dig for DNS queries
 
-DNS servers can be manually queried using DNS tools such as [`nslookup` (Windows and Linux clients)](/windows-server/administration/windows-commands/nslookup) and [`dig` (Linux clients)](https://linux.die.net/man/1/dig). Using these tools is helpful in scenarious including trying to verify functionality of services, testing hostname/IP resolution, searching for existing/stale DNS records, checking server configuration, verifying TTL. You can also use the [Azure connection troubleshooter](/azure/network-watcher/connection-troubleshoot-overview) for additional problem solving.
+DNS servers can be manually queried using DNS tools such as [`nslookup` (Windows and Linux clients)](/windows-server/administration/windows-commands/nslookup) and [`dig` (Linux clients)](https://linux.die.net/man/1/dig). Using these tools is helpful in scenarios including trying to verify functionality of services, testing hostname/IP resolution, searching for existing/stale DNS records, checking server configuration, verifying TTL. You can also use the [Azure connection troubleshooter](/azure/network-watcher/connection-troubleshoot-overview) for additional problem solving.
 
 The `nslookup` and `dig` commands can be run from a remote connection to the VM (such as from Bastion) or directly to the VM via the [run command option](/azure/virtual-machines/run-command-overview) on the VM itself.