Moving Beyond Hardcoded IPs with Consul DNS Service Discovery

Hardcoding IP addresses in microservice configurations is a technical debt that inevitably breaks during scaling events or infrastructure migrations. In dynamic environments where containers or virtual machines spin up and down constantly, IP addresses are ephemeral. If Service A expects to find Service B at a static IP, the system fails the moment Service B restarts.

The most robust way to solve this is through service discovery. By using Consul's DNS interface, your applications can resolve services using standard names—like order-api.service.consul—without needing Consul-specific libraries or complex client logic.

How the Consul DNS Interface Works

Consul acts as a central registry. When a service starts, it registers itself with the Consul agent, providing its IP and port. Consul then monitors the service via health checks. If an instance fails its health check, Consul marks it as unhealthy.

When an application performs a DNS lookup for a service name, the Consul DNS interface returns only the IP addresses of the healthy instances. By default, Consul uses round-robin load balancing to rotate the IP addresses returned, allowing the client to distribute traffic across the available pool automatically.

Practical Example: Registering and Resolving a Service

To demonstrate, we will register a simple HTTP web service named "payment-processor" and resolve it using DNS. This assumes you have a Consul agent running locally on localhost.

First, register the service using the Consul CLI. This command tells Consul where the service lives and how to check its health:

consul service register payment-processor \
  -address=127.0.0.1 \
  -port=8080 \
  -check-http="http://127.0.0.1:8080/health" \
  -check-interval=10s

Once registered, you can use standard DNS tools like dig to resolve the service. Run this command to query the local Consul agent (usually on port 863):

dig @localhost payment-processor.service.consul

The expected output will show the A record containing the IP address of your healthy instance:

;; ANSWER SECTION:
payment-processor.service.consul. 10s IN  A  127.0.0.1

The 'DNS Caching' Pitfall

The biggest risk when using DNS-based service discovery is client-side caching. If your application or the underlying OS caches the DNS response for too long (a high TTL - Time To Live), it will continue to send traffic to a dead instance even after Consul has marked it as unhealthy.

To mitigate this, ensure:

• The TTL in Consul registration is set low (the default is 10 seconds).
• Your application runtime (e.g., the JVM) is configured to respect DNS TTL values rather than caching them indefinitely.
• The OS-level resolver (like nsdd on Linux) is configured with short timeouts.

Trade-offs: DNS vs. Service Mesh

While the DNS interface is easy to implement because it requires no code changes, it has limitations. It provides basic round-robin load balancing. If you require advanced patterns like canary deployments, header-based routing, or mutual TLS (mTLS), DNS alone will not be enough. In those cases, you would need to move to a service mesh like Consul Connect, which uses Envoy proxies to handle traffic.

For most teams moving from static configurations to dynamic environments, the Consul DNS interface is the highest-leverage point available. It decouples the network location from the application logic without the overhead of a full sidecar mesh.