When an application stops responding, one of the first diagnoses is often: “it’s a DNS problem.” In many cases, it is, but sometimes the real issue lies in the Service Discovery system. Although both mechanisms help locate resources on a network, they serve very different functions and operate at different levels of the infrastructure.
The advent of Kubernetes, Docker, microservices, and cloud-native architectures has made these concepts coexist constantly, leading to common confusion—even among experienced system administrators. The truth is that DNS and Service Discovery do not compete; they complement each other.
The key points of DNS and Service Discovery in 20 seconds
- DNS translates domain names into IP addresses to locate servers.
- Service Discovery allows applications to automatically find other applications.
- Cloud environments constantly change IPs, making traditional DNS insufficient.
- Kubernetes combines both mechanisms to provide a dynamic and resilient infrastructure.
If the previous article about CDN and cache explained how to accelerate content access, DNS and Service Discovery solve another problem: how to correctly locate services when the infrastructure is constantly changing.
DNS: the phone directory of the Internet
The Domain Name System (DNS) has been around since the early days of the Internet and continues to be one of its fundamental pillars.
Its function is to convert easy-to-remember names, such as:
- google.com
- github.com
- stackoverflow.com
into the IP addresses that computers actually use to communicate.
For example, when a user types:
www.example.comtheir device queries the DNS server for the associated IP address.
The response could be:
203.0.113.10From that moment, the browser knows where to send the request.
All this process usually completes in just a few milliseconds and is virtually transparent to the user.
Without DNS, we would need to memorize the IP address of every website we visit.
The problem: modern applications are no longer static servers
For many years, servers barely changed.
A company would install a physical server or a virtual machine and keep the same IP address for months or even years.
In that scenario, DNS worked perfectly.
But modern architecture is completely different.
Today, an application can be composed of dozens or hundreds of small, independent services.
Each of these can run on:
- Docker Containers.
- Kubernetes Pods.
- Virtual Machines.
- Serverless functions.
- Cloud instances that appear and disappear automatically.
In this environment, IP addresses change constantly.
This is where Service Discovery comes into play.
What is Service Discovery
Service Discovery allows an application to automatically find another application without pre-knowledge of its IP address.
Instead of asking:
Where is 10.25.17.84?it asks:
Where is Payment Service?The system responds with the instance available at that moment.
Thus, if a container disappears and Kubernetes creates another with a completely different IP, the rest of the services keep functioning without changing a single line of configuration.
Applications only know the logical name of the service.
The discovery system takes care of the rest.
A simple example
Imagine an e-commerce store based on microservices.
It consists of:
- User Service
- Product Service
- Order Service
- Payment Service
- Notification Service
When a customer makes a purchase, the order service needs to communicate with the payment service.
If it used IP addresses directly, restarting the container would break communication.
Yesterday:
Payment Service
192.168.10.25After a restart:
Payment Service
192.168.10.61The IP has changed.
Without Service Discovery, all applications using that service would need manual updates.
With Service Discovery, simply ask:
Where is Payment Service?The system automatically responds with the new location.
From the application’s perspective, nothing has changed.
Kubernetes automates the entire process
Kubernetes includes Service Discovery natively.
When a Service resource is created, it automatically generates an internal DNS name such as:
payment-service.default.svc.cluster.localApplications simply make requests using:
http://payment-serviceThey don’t need to know:
- How many Pods there are,
- What IPs they have,
- Which one just restarted,
- Which has been replaced.
Kubernetes automatically keeps this information updated.
If a Pod fails, traffic is redirected to another available one without the client application needing to change anything.
This combination of internal DNS and Service Discovery is one of Kubernetes’ core pillars.
DNS and Service Discovery address different problems
While both help locate resources, they operate at different levels.
| DNS | Service Discovery |
|---|---|
| Locates servers. | Locates applications or services. |
| Translates domain names to IPs. | Automatically finds available instances. |
| Designed for relatively stable infrastructure. | Built for dynamic, cloud-native environments. |
| Used by external users and applications. | Primarily used among microservices. |
| Changes infrequently. | Updated continuously. |
The difference can be summarized as:
DNS helps people find servers.
Service Discovery helps applications find each other.
A real-world example: Netflix
When a user types:
www.netflix.comthe first step is resolving that domain via DNS.
Once the request reaches Netflix’s infrastructure, a completely different process begins.
Dozens of internal services start communicating with each other:
- Authentication,
- Profiles,
- Recommendations,
- Catalog,
- Billing,
- Playback,
- Monitoring.
These components typically don’t use public names.
Instead, they employ Service Discovery systems to locate available instances of each microservice in real-time.
To the user, it all appears as a single application.
Internally, hundreds of services distributed across multiple data centers may be involved.
Service Discovery does not replace DNS
A common misconception is that Kubernetes has replaced traditional DNS.
That’s not true.
What Kubernetes does is use DNS as a mechanism to implement part of its internal Service Discovery.
In fact, both work together.
The usual flow is:
- The user uses DNS to locate the application.
- The request arrives at the cluster.
- Within the cluster, microservices use Service Discovery to find each other.
- Kubernetes automatically updates routes as new instances appear or disappear.
The cloud infrastructure needs both
Modern applications no longer run on just a few static servers.
Auto-scaling, continuous deployment, containers, and orchestration mean IPs change constantly.
DNS remains essential for accessing applications and services from the internet.
Service Discovery ensures that applications continue functioning properly even as infrastructure changes hundreds of times a day.
That’s why technologies like Kubernetes, Consul, Istio, Linkerd, or AWS Cloud Map incorporate advanced service discovery mechanisms.
They do not replace DNS.
They complement it.
In practice, any modern cloud-native architecture requires both mechanisms working together to provide high availability, scalability, and resilience.
Frequently Asked Questions
Are DNS and Service Discovery the same?
No. DNS translates domain names into IP addresses, whereas Service Discovery allows applications or microservices to automatically locate each other, even as their location changes.
Why does Kubernetes use both?
Because DNS provides stable names to access services, while Kubernetes automatically updates which healthy Pods respond behind those names.
Can an application work with only DNS?
Yes, especially in traditional infrastructure where IPs rarely change. In microservice architectures, maintaining that manually becomes significantly more difficult.
What other Service Discovery solutions exist besides Kubernetes?
Some of the most well-known include HashiCorp Consul, AWS Cloud Map, Eureka by Netflix, and built-in mechanisms in platforms like Kubernetes or OpenShift.
