mirror of https://github.com/hashicorp/consul
42 lines
3.5 KiB
Markdown
42 lines
3.5 KiB
Markdown
---
|
||
layout: docs
|
||
page_title: DNS usage overview
|
||
description: >-
|
||
For service discovery use cases, Domain Name Service (DNS) is the main interface to look up, query, and address Consul nodes and services. Learn how a Consul DNS lookup can help you find services by tag, name, namespace, partition, datacenter, or domain.
|
||
---
|
||
|
||
# DNS usage overview
|
||
|
||
This topic provides overview information about how to look up Consul nodes and services using the Consul DNS.
|
||
|
||
## Consul DNS
|
||
The Consul DNS is the primary interface for discovering services registered in the Consul catalog. The DNS enables you to look up services and nodes registered with Consul using terminal commands instead of making HTTP API requests to Consul.
|
||
|
||
We recommend using the DNS for service discovery in virtual machine (VM) environments because it removes the need to modify native applications so that they can consume the Consul service discovery APIs.
|
||
|
||
The DNS has several default configurations, but you can customize how the server processes lookups. Refer to [Configure DNS Behaviors](/consul/docs/services/discovery/dns-configuration) for additional information.
|
||
|
||
### DNS versus native app integration
|
||
You can use DNS to reach services registered with Consul or modify your application to natively consume the Consul service discovery HTTP APIs.
|
||
|
||
We recommend using the DNS because it is less invasive. You do not have to modify your application with Consul to retrieve the service’s connection information. Instead, you can use a DNS fully qualified domain (FQDN) that conforms to Consul's lookup format to retrieve the relevant information.
|
||
|
||
Refer to [ Native App Integration](/consul/docs/connect/native) and its [Go package](/consul/docs/connect/native/go) for additional information.
|
||
|
||
### DNS versus upstreams
|
||
If you are using Consul for service discovery and have not enabled service mesh features, then use the DNS to discover services and nodes in the Consul catalog.
|
||
|
||
If you are using Consul for service mesh on VMs, you can use upstreams or DNS. We recommend using upstreams because you can query services and nodes without modifying the application code or environment variables. Refer to [Upstream Configuration Reference](/consul/docs/connect/registration/service-registration#upstream-configuration-reference) for additional information.
|
||
|
||
If you are using Consul on Kubernetes, refer to [the upstreams annotation documentation](/consul/docs/k8s/annotations-and-labels#consul-hashicorp-com-connect-service-upstreams) for additional information.
|
||
|
||
## Static queries
|
||
Node lookups and service lookups are the fundamental types of static queries. Depending on your use case, you may need to use different query methods and syntaxes to query the DNS for services and nodes.
|
||
|
||
Consul relies on a very specific format for queries to resolve names. Note that all queries are case-sensitive.
|
||
|
||
Refer to [Perform Static DNS Lookups](/consul/docs/services/discovery/dns-static-lookups) for details about how to perform node and service lookups.
|
||
|
||
## Prepared queries
|
||
Prepared queries are configurations that enable you to register complex DNS queries. They provide lookup features that extend Consul's service discovery capabilities, such as filtering by multiple tags and automatically querying remote datacenters for services if no healthy nodes are available in the local datacenter. You can also create prepared query templates that match names using a prefix match, allowing a single template to apply to potentially many services. Refer to [Enable Dynamic DNS Queries](/consul/docs/services/discovery/dns-dynamic-lookups) for additional information.
|