You deploy a new version of your microservice and the old containers are killed instantly. You update your internal DNS records to point to the new IP addresses. However, for the next five minutes, your API gateway continues to send 40 percent of your traffic to the dead containers. Your logs are filled with connection timeouts and your error rate is spiking. This is the classic DNS staleness trap that plagues modern distributed systems.
The problem lies in the fundamental design of how we locate resources. Traditional DNS was built for a world where servers lived for years. In a modern cloud environment, servers might only live for minutes. Relying on static naming systems to manage high-churn infrastructure creates a gap between where your traffic is going and where your healthy services actually live.
This article explores the technical differences between DNS vs service discovery, why the distinction matters for your uptime, and how to choose the right strategy for your DevOps architecture.
DNS vs service discovery: defining the map and the radar
At its core, DNS is a distributed, hierarchical naming system. It acts like the Yellow Pages for the internet. You give it a hostname, and it returns an IP address. It is incredibly efficient and globally ubiquitous. Every programming language and operating system knows how to talk to it.
Service discovery is a more specialized control plane. Instead of just a static map, it acts like a live radar system. It tracks the dynamic state of every service instance in your cluster. While DNS tells you where a service should be, service discovery tells you where it is right now.
A service discovery system like Consul or the internal registry in Kubernetes maintains a “service catalog.” This catalog is a live database of every running instance. When a new container starts, it registers itself with the catalog. When it shuts down, it is removed. This happens in milliseconds, far faster than traditional DNS propagation.
The TTL problem and DNS caching
The biggest hurdle in using DNS for microservices is Time-To-Live (TTL). DNS relies heavily on caching to prevent every single request from hammering the root name servers. Your operating system caches the result. Your browser caches the result. Your API gateway caches the result.
If you set a high TTL, your service changes are slow to propagate. If you set a very low TTL (like 0 or 1 second), you might overwhelm your DNS server with lookups. Even worse, some runtimes ignore the TTL entirely. The JVM, for example, caches a successful lookup for 30 seconds by default and forever when a security manager is set, so it can keep a stale IP until the process restarts.
| Feature | DNS | Service Discovery |
|---|---|---|
| Primary Goal | Human-readable name to IP | Dynamic instance tracking |
| Propagation | Slow (TTL dependent) | Near-instant (Gossip/Streaming) |
| Metadata | Very limited (TXT records) | Rich (tags, version, region) |
| Client Support | Native in all OS | Often requires API/Agent |
| Health Awareness | None (Static) | Active monitoring |
Service discovery solves this by moving away from deep-level caching. Clients or load balancers often maintain a streaming connection to the registry. When a service instance moves, the registry pushes a notification to all subscribers. There is no waiting for a cache to expire. The system converges on the new state almost instantly.
Health awareness: the core differentiator
A standard DNS server is oblivious to the health of the IP addresses it returns. If a server rack loses power, the DNS record still points to those IPs. You have to manually update the record or run a custom script to change it.
Service discovery systems treat health as a first-class citizen. They perform active health checks on every registered instance. These checks can be as simple as a TCP probe or as complex as a custom HTTP endpoint that checks database connectivity.
If a health check fails, the instance is automatically marked as “unhealthy” in the registry. The discovery system then stops returning that IP address to clients. This provides a level of self-healing that is impossible with vanilla DNS, and it pairs naturally with the signals you already collect through logging and monitoring. If you are hosting a SaaS on Docker, automated health-aware routing is the difference between a minor blip and a major outage.
Metadata and rich discovery
DNS is built to return a single type of data: an IP address. While you can use SRV records to include port numbers or TXT records for strings, the interface is clunky. It does not support complex queries.
Service discovery allows for metadata-driven routing. You can ask the registry for “all healthy instances of the ‘orders’ service running version 2.1 in the ‘us-east-1’ region.” This unlocks advanced deployment patterns like:
- Canary Deployments: Routing only 5 percent of traffic to a specific version tag.
- Blue/Green Deployments: Swapping traffic between service sets by changing a metadata flag.
- Locality-Aware Routing: Directing traffic to the instance physically closest to the requester to reduce latency.
This level of granularity is essential for scaling complex systems where simple round-robin load balancing is not enough.
How modern orchestrators bridge the gap
You might notice that in Kubernetes, you still use DNS names to talk to services. You might call http://order-service.default.svc.cluster.local. Does this mean Kubernetes just uses DNS?
Not exactly. Kubernetes uses a hybrid approach. It runs a service called CoreDNS, but CoreDNS is not backed by static zone files. It is plugged directly into the Kubernetes API. When a Pod starts or dies, the control plane updates the Service and EndpointSlice objects. CoreDNS watches those objects through the API and updates its responses in real time.
In this model, DNS is just the “wire protocol.” It is the interface that the application uses because it is easy and standard. However, the backend is a fully dynamic Service Discovery engine. This gives you the best of both worlds: the simplicity of DNS and the speed of Service Discovery.
Implementation strategies: when to use which?
Choosing between DNS vs service discovery depends on your infrastructure scale and churn rate.
If you are running a monolithic application on a few virtual machines that rarely change, DNS is perfectly fine. You can manage your records with simple automation or even manually. The complexity of a dedicated discovery system would outweigh the benefits.
However, if you are using containers, serverless functions, or microservices, you need a dynamic solution. If your IPs change every time you deploy or scale, DNS will eventually break your traffic flow.
For many developers, the best path is to use a tool that provides a DNS interface on top of a dynamic registry. HashiCorp Consul is a popular choice for this. It allows you to query the registry via a standard DNS lookup, but it handles the health checking and registration logic behind the scenes.
Takeaways
- DNS is for stability: Use it for external traffic, long-lived resources, and cross-company communication where caching is an advantage.
- Service Discovery is for churn: Use it for internal microservices, containers, and autoscaling groups where instances appear and disappear frequently.
- Mind the Cache: Never rely on vanilla DNS for sub-minute failover because client-side caching will almost always outlive your records.
- Health is Binary: Without active health checks, your discovery system is just a list of guesses. Always integrate automated liveness and readiness probes.
- Hybrid is Best: Use a discovery engine (like Kubernetes or Consul) that exposes a DNS interface. This simplifies your application code while keeping your infrastructure dynamic.
When was the last time a stale DNS record caused a production incident in your environment? If you’re untangling service routing for a high-churn stack, here’s how I help teams ship it.
