github
/
consul
mirror of https://github.com/hashicorp/consul
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
Browse Source

docs: agent/dns: minor fixes

pull/500/head
Dan Frost 10 years ago
parent
3bbb226e2b
commit
65ffbed02e
1 changed files with 18 additions and 17 deletions
Whitespace
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Unified View
Diff Options
Show Stats Download Patch File Download Diff File
  1. 35
      website/source/docs/agent/dns.html.markdown

35
website/source/docs/agent/dns.html.markdown
Unescape View File

@ -8,22 +8,23 @@ description: |-
# DNS Interface # DNS Interface
One of the primary query interfaces for Consul is using DNS. One of the primary query interfaces for Consul is DNS.
The DNS interface allows applications to make use of service The DNS interface allows applications to make use of service
discovery without any high-touch integration with Consul. For discovery without any high-touch integration with Consul. For
example, instead of making any HTTP API requests to Consul, example, instead of making HTTP API requests to Consul,
a host can use the DNS server directly and just do a name lookup a host can use the DNS server directly and just do a name lookup
for "redis.service.east-aws.consul". for "redis.service.east-aws.consul".
This query automatically translates to a lookup of nodes that This query automatically translates to a lookup of nodes that
provide the redis service, located in the "east-aws" datacenter, provide the redis service, are located in the "east-aws" datacenter,
with no failing health checks. It's that simple! and have no failing health checks. It's that simple!
There are a number of [configuration options](/docs/agent/options.html) that There are a number of [configuration options](/docs/agent/options.html) that
are important for the DNS interface. They are `client_addr`, `ports.dns`, `recursors`, are important for the DNS interface. They are `client_addr`, `ports.dns`, `recursors`,
`domain`, and `dns_config`. By default Consul will listen on 127.0.0.1:8600 for DNS queries `domain`, and `dns_config`. By default Consul will listen on 127.0.0.1:8600 for DNS queries
in the "consul." domain, without support for DNS recursion. All queries are case-insensitive, a in the "consul." domain, without support for DNS recursion. All queries are case-insensitive: a
name lookup for `PostgreSQL.node.dc1.consul` will find all nodes named `postgresql`, no matter of case. name lookup for `PostgreSQL.node.dc1.consul` will find all nodes named `postgresql`,
regardless of case.
There are a few ways to use the DNS interface. One option is to use a custom There are a few ways to use the DNS interface. One option is to use a custom
DNS resolver library and point it at Consul. Another option is to set Consul DNS resolver library and point it at Consul. Another option is to set Consul
@ -76,24 +77,24 @@ consul. 0 IN SOA ns.consul. postmaster.consul. 1392836399 3600 600 86400 0
## Service Lookups ## Service Lookups
A service lookup is the alternate type of query. It is used to query for service A service lookup is the alternate type of query. It is used to query for service
providers and supports two mode of lookup, a strict RCF style lookup and the providers and supports two lookup methods: standard lookup, and strict
standard lookup. [RFC 2782](https://tools.ietf.org/html/rfc2782) lookup.
### Standard Style Lookup ### Standard Lookup
The format of a standard service lookup is like the following: The format of a standard service lookup is:
[tag.]<service>.service[.datacenter][.domain] [tag.]<service>.service[.datacenter][.domain]
As with node lookups, the `datacenter` is optional, as is the `tag`. If no tag is As with node lookups, the `datacenter` is optional, as is the `tag`. If no tag is
provided, then no filtering is done on tag. So, if we want to find any redis service provided, then no filtering is done on tag. So, if we want to find any redis service
providers in our local datacenter, we could lookup "redis.service.consul.", however providers in our local datacenter, we could lookup "redis.service.consul.", while
if we care about the PostgreSQL master in a particular datacenter, we could lookup if we care about the PostgreSQL master in a particular datacenter, we could lookup
"master.postgresql.service.dc2.consul." "master.postgresql.service.dc2.consul."
The DNS query system makes use of health check information to prevent routing The DNS query system makes use of health check information to prevent routing
to unhealthy nodes. When a service query is made, any services failing their health to unhealthy nodes. When a service query is made, any services failing their health
check, or failing a node system check will be omitted from the results. To allow check, or failing a node system check, will be omitted from the results. To allow
for simple load balancing, the set of nodes returned is also randomized each time. for simple load balancing, the set of nodes returned is also randomized each time.
These simple mechanisms make it easy to use DNS along with application level retries These simple mechanisms make it easy to use DNS along with application level retries
as a simple foundation for an auto-healing service oriented architecture. as a simple foundation for an auto-healing service oriented architecture.
@ -124,13 +125,13 @@ consul.service.consul. 0 IN SRV 1 1 8300 foobar.node.dc1.consul.
foobar.node.dc1.consul. 0 IN A 10.1.10.12 foobar.node.dc1.consul. 0 IN A 10.1.10.12
``` ```
### RFC-2782 Style Lookup ### RFC 2782 Lookup
The format for RFC style lookups uses the following format: The format for RFC 2782 SRV lookups is:
_<service>._<protocol>.service[.datacenter][.domain] _<service>._<protocol>.service[.datacenter][.domain]
Per [RFC-2782](https://www.ietf.org/rfc/rfc2782.txt), SRV queries should use Per [RFC 2782](https://tools.ietf.org/html/rfc2782), SRV queries should use
underscores (_) as a prefix to the `service` and `protocol` values in a query to underscores (_) as a prefix to the `service` and `protocol` values in a query to
prevent DNS collisions. The `protocol` value can be any of the tags for a prevent DNS collisions. The `protocol` value can be any of the tags for a
service or if the service has no tags, the value "tcp" should be used. If "tcp" service or if the service has no tags, the value "tcp" should be used. If "tcp"
@ -139,7 +140,7 @@ is specified as the protocol, the query will not perform any tag filtering.
Other than the query format and default "tcp" protocol/tag value, the behavior Other than the query format and default "tcp" protocol/tag value, the behavior
of the RFC style lookup is the same as the standard style of lookup. of the RFC style lookup is the same as the standard style of lookup.
Using the RCF style lookup, If you registered the service "rabbitmq" on port Using RFC 2782 lookup, If you registered the service "rabbitmq" on port
5672 and tagged it with "amqp" you would query the SRV record as 5672 and tagged it with "amqp" you would query the SRV record as
"_rabbitmq._amqp.service.consul" as illustrated in the example below: "_rabbitmq._amqp.service.consul" as illustrated in the example below:
@ -168,7 +169,7 @@ rabbitmq.node1.dc1.consul. 0 IN A 10.1.11.20
When the DNS query is performed using UDP, Consul will truncate the results When the DNS query is performed using UDP, Consul will truncate the results
without setting the truncate bit. This is to prevent a redundant lookup over without setting the truncate bit. This is to prevent a redundant lookup over
TCP which generate additional load. If the lookup is done over TCP, the results TCP that generates additional load. If the lookup is done over TCP, the results
are not truncated. are not truncated.
## Caching ## Caching

Write Preview
Loading…
Cancel
Save