Apply suggestions from code review

Co-authored-by: Aimee Ukasick <aimee.ukasick@hashicorp.com>
Co-authored-by: Blake Covarrubias <blake@covarrubi.as>

website/content/docs/k8s/dns/views/enable.mdx

@@ -18,7 +18,7 @@ You must meet the following minimum application versions to enable the Consul DN
 
 ## Update Helm values
 
-To enable the Consul DNS proxy, add the required [Helm values](/consul/docs/k8s/helm) to your Consul on Kubernetes deployment:
+To enable the Consul DNS proxy, add the required [Helm values](/consul/docs/k8s/helm) to your Consul on Kubernetes deployment.
 
 ```yaml
 connectInject:
@@ -30,7 +30,7 @@ dns:
 
 ### ACLs
 
-We recommend you create a dedicated [ACL token with DNS permissions](/consul/docs/security/acl/tokens/create/create-a-dns-token) for the Consul DNS proxy. The Consul DNS proxy requires the following ACL permissions:
+We recommend you create a dedicated [ACL token with DNS permissions](/consul/docs/security/acl/tokens/create/create-a-dns-token) for the Consul DNS proxy. The Consul DNS proxy requires these ACL permissions.
 
 ```hcl
 node_prefix "" {
@@ -42,7 +42,7 @@ service_prefix "" {
 }
 ```
 
-You can manage ACL tokens with Consul on Kubernetes, or you can configure the DNS proxy to access a token stored in Kubernetes secret. To use a Kubernetes secret, add the following configuration to your Helm chart:
+You can manage ACL tokens with Consul on Kubernetes, or you can configure the DNS proxy to access a token stored in Kubernetes secret. To use a Kubernetes secret, add the following configuration to your Helm chart.
 
 ```yaml
 dns:
@@ -54,7 +54,7 @@ dns:
 
 ## Retrieve Consul DNS proxy's address
 
-To look up the IP address for the Consul DNS proxy in the Kubernetes Pod, run the following command:
+To look up the IP address for the Consul DNS proxy in the Kubernetes Pod, fetch all services.
 
 ```shell-session
 $ kubectl get services –-all-namespaces
@@ -72,7 +72,7 @@ Note the `CLUSTER-IP` for the `consul-dns` service. Use this address when you up
 
 Create or update a [ConfigMap object in the Kubernetes cluster](https://kubernetes.io/docs/concepts/configuration/configmap/) so that Kubernetes forwards DNS requests with the `.consul` domain to the IP address of the Consul DNS proxy.
 
-The following example of a ConfigMap resource configures Kubernetes to forward Consul DNS requests in the cluster to the Consul DNS Proxy running on `10.150.0.1`.
+The following example of a ConfigMap resource configures Kubernetes to forward Consul DNS requests in the cluster to the Consul DNS Proxy running on `10.96.148.46`.
 
 ```yaml
 apiVersion: v1
@@ -96,10 +96,10 @@ data:
         reload
         loadbalance
     }
-    consul.local:53 {
+    consul:53 {
         errors
         cache 30
-        forward . 10.150.0.1
+        forward . 10.96.148.46
     }  
 ```
 

website/content/docs/k8s/dns/views/index.mdx

@@ -7,7 +7,7 @@ description: ->
 
 # Consul DNS views for Kubernetes
 
-This topic describes how to schedule a dedicated Consul DNS proxy in a Kubernetes Pod so that Kubernetes Services can use Consul DNS addresses. You can use the Consul DNS proxy to enable service discovery across admin partitions in Kubernetes deployments without using agent gossip.
+This topic describes how to schedule a dedicated Consul DNS proxy in a Kubernetes Pod so that applications in Kubernetes can resolve Consul DNS addresses. You can use the Consul DNS proxy to enable service discovery across admin partitions in Kubernetes deployments without needing to deploy Consul client agents.
 
 ## Introduction
 
@@ -20,7 +20,7 @@ Consul on Kubernetes supports [configuring Kubernetes to resolve Consul DNS](/co
 
 The `consul-dns` proxy does not require the presence of Consul client agents or Consul dataplanes, removing gossip communication as a requirement for Consul DNS on Kubernetes. The proxy is also designed for deployment in a Kubernetes cluster with [external servers enabled](/consul/docs/k8s/deployment-configurations/servers-outside-kubernetes). When a cluster runs in a non-default admin partition and uses the proxy to query external servers, Consul automatically recognizes the admin partition that originated the request and returns service discovery results scoped to that specific admin partition.
 
-To use Consul DNS for service discovery on Kubernetes, deploy a `consul-proxy` service in each Kubernetes Pod that needs to resolve Consul DNS. Kubenetes will send all DNS requests to the Kubernetes controller first. The controller forwards requests for the `.consul` domain to the `consul-proxy` service, which then queries the Consul catalog and returns service discovery results.
+To use Consul DNS for service discovery on Kubernetes, deploy a `dns-proxy` service in each Kubernetes Pod that needs to resolve Consul DNS. Kubenetes will send all DNS requests to the Kubernetes controller first. The controller forwards requests for the `.consul` domain to the `dns-proxy` service, which then queries the Consul catalog and returns service discovery results.
 
 ## Workflows
 
@@ -36,8 +36,8 @@ For more information about the underlying concepts described in this workflow, r
 
 Consul on Kubernetes currently uses [Consul dataplanes](/consul/docs/connect/dataplane) by default. These lightweight processes provide Consul access to the sidecar proxies in the service mesh, but leave Kubernetes in charge of most other service discovery and service mesh operations.
 
-- **Use Kubernetes DNS and Consul DNS in a single deployment**. The Consul DNS proxy enables any Service in a Pod to resolve an address through Consul DNS without disrupting the underlying Kubernetes DNS functionality.
-- **Consul service discovery using less resources**. When you use the Consul DNS proxy for service discovery, you do not need to schedule Consul client agents or dataplanes as sidecars. One Kubernetes Service that uses the same resources as a single Consul dataplane provides Pods access to the Consul service catalog.
+- **Use Kubernetes DNS and Consul DNS in a single deployment**. The Consul DNS proxy enables any application in a Pod to resolve an address through Consul DNS without disrupting the underlying Kubernetes DNS functionality.
+- **Consul service discovery using fewer resources**. When you use the Consul DNS proxy for service discovery, you do not need to schedule Consul client agents or dataplanes as sidecars. One Kubernetes Service that uses the same resources as a single Consul dataplane provides Pods access to the Consul service catalog.
 - **Consul DNS without gossip communication**. The Consul DNS service runs on both Consul server and Consul client agents, which use [gossip communication](/consul/docs/security/encryption/gossip) to ensure that service discovery results are up-to-date. The Consul DNS proxy provides access to Consul DNS without the security overhead of agent-to-agent gossip.
 
 ## Constraints and limitations

website/content/docs/services/discovery/dns-cache.mdx

@@ -1,6 +1,6 @@
 ---
 layout: docs
-page_title: cale Consul DNS
+page_title: Scale Consul DNS
 description: ->
     You tune Consul DNS query handling to balance between current information and reducing request response time. Learn how to enable caching by modifying TTL values, how to return stale results from the DNS cache, and how to configure Consul for negative response caching.
 ---
@@ -14,7 +14,7 @@ This page describes the process to return cached results in response to DNS look
 By default, Consul serves all DNS results with a `0` TTL value so that it returns the most recent information. When operating at scale, this configuration may result in additional latency because servers must respond to every DNS query. There are several strategies for distributing this burden in your datacenter:
 
 - [Allow Stale Reads](#stale-reads). Allows other servers besides the leader to answer the query rather than forwarding it to the leader.
-- [Configure DNS TTLs](#ttl-values). Configure a TTL to nodes or services that the DNS subsystem on the service container’s OS uses. Services then resolve DNS queries locally without any external requests.  
+- [Configure DNS TTLs](#ttl-values). Configure DNS time-to-live (TTL) values for nodes or services so that the DNS subsystem on the container’s operating system can cache responses. Services then resolve DNS queries locally without any external requests.  
 - [Add Read Replicas](/consul/docs/enterprise/read-scale). Enterprise users can use read replicas, which are additional Consul servers that replicate cluster data without participating in the Raft quorum.
 - [Use Cache to prevent server requests](/consul/docs/agent/config/config-files#dns_use_cache). Configure the Consul client to use its agent cache to subscribe to events about a service or node. After you establish the watch, the local Consul client agent can resolve DNS queries about the service or node without querying Consul servers.