HashiCorp Consul is a service mesh solution that provides service discovery, configuration, and segmentation functionality. It operates with a Control Plane (Consul Servers) and a Data Plane (proxies alongside services).

Here is a detailed breakdown of the components you listed, along with other key parts of the Consul mesh architecture.

1. Consul Server (Control Plane)

• What it Does: The Consul Server is the core of the Control Plane. It stores and manages all cluster state, including:
  • Service catalog (what services exist, IPs, health status): Act as the source of truth for the whole mesh.
  • Service mesh configuration (intentions, service-resolver, splitter, router config)
  • Issue and rotate mTLS certificates.
  • Agent coordination and leader election
  • Key-value store (for configuration)
  • Coordinate multi-datacenter mesh.
  • Deliver configuration to Consul agents, proxies (Envoy), gateways.
• It maintains the central catalog of all registered services and their health information, stores service mesh configuration (like intentions for authorization), and acts as the Certificate Authority (CA) to issue mutual TLS (mTLS) certificates to all the proxies in the data plane for secure communication. It uses the Raft consensus algorithm to ensure high availability and consistency across a cluster of servers.
• Why it's Needed: It is the source of truth for the entire service mesh. Without it, Consul Agents/Proxies would have no service registry, security policy (intentions), or certificates, making service-to-service communication impossible or unsecured.

What happens if it does NOT exist?

• The mesh cannot function; no control plane exists.
• No service discovery — services won’t be able to resolve each other.
• No mTLS certificates — Envoy sidecars cannot establish trust.
• No intentions — no zero-trust policy enforcement.
• No consistent state.

Without Consul servers → the service mesh dies.

2. Consul DNS

• What it Does: Consul includes a built-in DNS server that allows services to discover each other using human-readable names rather than hardcoded IP addresses and ports. When a service queries for another service (e.g., web.service.consul), the Consul agent running on the node resolves this request by querying the Consul Server, which returns the IP address(es) of the healthy instances of that service.
• Why it's Needed: It provides an essential service discovery mechanism. It allows applications to use simple, consistent service names, abstracting away the dynamic and constantly changing network locations of microservices.