[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.
This commit is contained in:
Matt Keeler 2020-11-17 10:03:00 -05:00 committed by GitHub
parent 4dfcdbab26
commit a7d945e7b9
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
12 changed files with 13 additions and 13 deletions

View File

@ -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?

View File

@ -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

View File

@ -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`.

View File

@ -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).

View File

@ -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)

View File

@ -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**.

View File

@ -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.

View File

@ -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

View File

@ -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

View File

@ -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.

View File

@ -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

View File

@ -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