minor fixes

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

@@ -1,6 +1,6 @@
 ---
 layout: docs
-page_title: Consul DNS views for Kubernetes
+page_title: Enable Consul DNS proxy for Kubernetes
 description: ->
     Learn how to schedule a Consul DNS proxy for a Kubernetes Pod so that your services can return Consul DNS results for service discovery.
 ---

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

@@ -37,26 +37,6 @@ Consul on Kubernetes currently uses [Consul dataplanes](/consul/docs/connect/dat
 - **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. One Kubernetes Service that uses the same resources as a single Consul dataplane provides the entire Pod access to the Consul 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.
 
-## Scaling techniques
-
-By default, Consul forwards all DNS requests to the current leader in the Consul server cluster. When operating at scale, this configuration may result in longer response times because a single server must respond to every DNS query. There are several strategies for distributing this burden in your datacenter:
-
-- [Allow Stale Reads](/consul/docs/services/discovery/dns-cache#stale-reads). Allows other servers besides the leader to answer the query rather than forwarding it to the leader.
-- [Configure DNS TTLs](/consul/docs/services/discovery/dns-cache#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.  
-- [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.
-
-The following table describes the availability of each scaling technique depending on whether you configure Consul to offload DNS requests from the cluster leader to a client agent, dataplane, or DNS proxy.
-
-| Scaling technique                   | Supported by Consul DNS Proxy |
-| :---------------------------------- | :---------------------------: |
-| Configure DNS TTLs                  | ✅                       |
-| Allow Stale Reads                   | ✅                       |
-| Add Read Replicas                   | ✅                       |
-| Use Cache to prevent server request | ❌                      |
-
-For more information about considerations for Consul deployments that operate at scale, refer to [Operating Consul at Scale](/consul/docs/architecture/scale).
-
 ## Constraints and limitations
 
 If you experience issues using the Consul DNS proxy for Kubernetes, refer to the following list of technical constraints and limitations.

website/data/docs-nav-data.json

@@ -1672,7 +1672,7 @@
               },
               {
                 "title": "Enable Consul DNS proxy",
-                "path": "k8s/dns/views"
+                "path": "k8s/dns/views/enable"
               }
             ]
           },