[docs] Change links to the DNS information to the right place (#8675)

The redirects were working in many situations but some (INTERNALS.md) was not. This just flips everything over to using the real link.

contributing/INTERNALS.md

@@ -59,7 +59,7 @@ This section addresses some frequently asked questions about Consul's architectu
 
 ### How does eventually-consistent gossip relate to the Raft consensus protocol?
 
-When you query Consul for information about a service, such as via the [DNS interface](https://www.consul.io/docs/agent/dns.html), the agent will always make an internal RPC request to a Consul server that will query the consistent state store. Even though an agent might learn that another agent is down via gossip, that won't be reflected in service discovery until the current Raft leader server perceives that through gossip and updates the catalog using Raft. You can see an example of where these layers are plumbed together here - https://github.com/hashicorp/consul/blob/v1.0.5/agent/consul/leader.go#L559-L602.
+When you query Consul for information about a service, such as via the [DNS interface](https://www.consul.io/docs/discovery/dns), the agent will always make an internal RPC request to a Consul server that will query the consistent state store. Even though an agent might learn that another agent is down via gossip, that won't be reflected in service discovery until the current Raft leader server perceives that through gossip and updates the catalog using Raft. You can see an example of where these layers are plumbed together here - https://github.com/hashicorp/consul/blob/v1.0.5/agent/consul/leader.go#L559-L602.
 
 ## Why does a blocking query sometimes return with identical results?
 

website/pages/api-docs/query.mdx

@@ -12,7 +12,7 @@ The `/query` endpoints create, update, destroy, and execute prepared queries.
 Prepared queries allow you to register a complex service query and then execute
 it later via its ID or name to get a set of healthy nodes that provide a given
 service. This is particularly useful in combination with Consul's
-[DNS Interface](/docs/agent/dns) as it allows for much richer queries than
+[DNS Interface](/docs/discovery/dns) as it allows for much richer queries than
 would be possible given the limited entry points exposed by DNS.
 
 Check the [Geo Failover tutorial](https://learn.hashicorp.com/tutorials/consul/automate-geo-failover) for details and

website/pages/docs/agent/config-entries/ingress-gateway.mdx

@@ -38,7 +38,7 @@ gateway:
 - The ingress gateway will route traffic based on the host/authority header,
   expecting a value matching `<service-name>.ingress.*`, or if using namespaces,
   `<service-name>.ingress.<namespace>.*`. This matches the [Consul DNS
-  ingress subdomain](/docs/agent/dns#ingress-service-lookups).
+  ingress subdomain](/docs/discovery/dns#ingress-service-lookups).
 
 A wildcard specifier cannot be set on a listener of protocol `tcp`.
 

website/pages/docs/agent/options.mdx

@@ -1452,7 +1452,7 @@ Valid time units are 'ns', 'us' (or 'µs'), 'ms', 's', 'm', 'h'."
     When set to true, in a DNS query for a service, the label between the domain
     and the `service` label will be treated as a namespace name instead of a datacenter.
     When set to false, the default, the behavior will be the same as non-Enterprise
-    versions and will assume the label is the datacenter. See: [this section](/docs/agent/dns#namespaced-services)
+    versions and will assume the label is the datacenter. See: [this section](/docs/discovery/dns#namespaced-services)
     for more details.
 
 - `domain` Equivalent to the [`-domain` command-line flag](#_domain).

website/pages/docs/connect/gateways/ingress-gateway.mdx

@@ -23,7 +23,7 @@ to a set of backing
 [services](/docs/agent/config-entries/ingress-gateway#services).
 
 To enable easier service discovery, a new Consul [DNS
-subdomain](/docs/agent/dns#ingress-service-lookups) is provided, on
+subdomain](/docs/discovery/dns#ingress-service-lookups) is provided, on
 `<service>.ingress.<domain>`.
 
 For listeners with a
@@ -32,7 +32,7 @@ For listeners with a
 case, the ingress gateway relies on host/authority headers to decide the
 service that should receive the traffic. The host used to match traffic
 defaults to the [Consul DNS ingress
-subdomain](/docs/agent/dns#ingress-service-lookups), but can be changed using
+subdomain](/docs/discovery/dns#ingress-service-lookups), but can be changed using
 the [hosts](/docs/agent/config-entries/ingress-gateway#hosts) field.
 
 ![Ingress Gateway Architecture](/img/ingress-gateways.png)

website/pages/docs/connect/native/index.mdx

@@ -52,7 +52,7 @@ Details on the steps are below:
 
 - **Service discovery** - This is normal service discovery using Consul,
   a static IP, or any other mechanism. If you're using Consul DNS, the
-  [`<service>.connect`](/docs/agent/dns#connect-capable-service-lookups)
+  [`<service>.connect`](/docs/discovery/dns#connect-capable-service-lookups)
   syntax to find Connect-capable endpoints for a service. After service
   discovery, choose one address from the list of **service addresses**.
 

website/pages/docs/connect/proxies/index.mdx

@@ -32,7 +32,7 @@ switch service definitions for registering proxies.
 If an application requires dynamic dependencies that are only available
 at runtime, it must [natively integrate](/docs/connect/native)
 with Connect. After natively integrating, the HTTP API or
-[DNS interface](/docs/agent/dns#connect-capable-service-lookups)
+[DNS interface](/docs/discovery/dns#connect-capable-service-lookups)
 can be used.
 
 !> Connect proxies do not currently support dynamic upstreams.

website/pages/docs/connect/proxies/managed-deprecated.mdx

@@ -119,7 +119,7 @@ default managed proxy and starts a listener for that service:
 
 The listener is started on random port within the configured Connect
 port range. It can be discovered using the
-[DNS interface](/docs/agent/dns#connect-capable-service-lookups)
+[DNS interface](/docs/discovery/dns#connect-capable-service-lookups)
 or
 [Catalog API](#).
 In most cases, service-to-service communication is established by

website/pages/docs/discovery/services.mdx

@@ -355,7 +355,7 @@ services {
 
 ## Service and Tag Names with DNS
 
-Consul exposes service definitions and tags over the [DNS](/docs/agent/dns)
+Consul exposes service definitions and tags over the [DNS](/docs/discovery/dns)
 interface. DNS queries have a strict set of allowed characters and a
 well-defined format that Consul cannot override. While it is possible to
 register services or tags with names that don't match the conventions, those

website/pages/docs/k8s/dns.mdx

@@ -11,7 +11,7 @@ description: >-
 # Consul DNS on Kubernetes
 
 One of the primary query interfaces to Consul is the
-[DNS interface](/docs/agent/dns). You can configure Consul DNS in
+[DNS interface](/docs/discovery/dns). You can configure Consul DNS in
 Kubernetes using a
 [stub-domain configuration](https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/#configure-stub-domain-and-upstream-dns-servers)
 if using KubeDNS or a [proxy configuration](https://coredns.io/plugins/proxy/) if using CoreDNS.

website/pages/docs/k8s/service-sync.mdx

@@ -21,7 +21,7 @@ automatically installed and configured using the
 Consul catalog enable Kubernetes services to be accessed by any node that
 is part of the Consul cluster, including other distinct Kubernetes clusters.
 For non-Kubernetes nodes, they can access services using the standard
-[Consul DNS](/docs/agent/dns) or HTTP API.
+[Consul DNS](/docs/discovery/dns) or HTTP API.
 
 **Why sync Consul services to Kubernetes?** Syncing Consul services to
 Kubernetes services enables non-Kubernetes services (such as external to

website/pages/intro/getting-started/agent.mdx

@@ -103,7 +103,7 @@ $ curl localhost:8500/v1/catalog/nodes
 [{"Node":"Armons-MacBook-Air","Address":"127.0.0.1","TaggedAddresses":{"lan":"127.0.0.1","wan":"127.0.0.1"},"CreateIndex":4,"ModifyIndex":110}]
 ```
 
-In addition to the HTTP API, the [DNS interface](/docs/agent/dns) can
+In addition to the HTTP API, the [DNS interface](/docs/discovery/dns) can
 be used to query the node. Note that you have to make sure to point your DNS
 lookups to the Consul agent's DNS server which runs on port 8600 by default.
 The format of the DNS entries (such as "Armons-MacBook-Air.node.consul") will