{
  "id": 3993879,
  "title": "How Does One Server Find Another Server? DNS, Private DNS, and Service Discovery Explained",
  "url": "https://urgent.news/2026/08/28/how-does-one-server-find-another-server-dns-private-dns-and-service",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-28T16:53:49.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/anik_sikder_313/how-does-one-server-find-another-server-dns-private-dns-and-service-discovery-explained-47ae"
  },
  "original_language": "en",
  "account": "In this article series, we've explored how servers within cloud environments like AWS, Azure, GCP, or private data centers can communicate over private networks without using the public internet or public IP addresses. The question then arises: how does one server discover another server when it needs to connect?\n\nThis seemingly simple question led to the development of DNS (Domain Name System), Private DNS, and Service Discovery mechanisms. These technologies have become crucial in distributed systems architecture.\n\nTo illustrate, let's imagine moving into a new city. Instead of memorizing the GPS coordinates of every building, we use names like city-hospital.com to easily find locations. Similarly, computers prefer names over IP addresses. DNS acts like the internet's phonebook, translating human-friendly names into machine-readable IP addresses. When you visit a website, your browser first asks a DNS resolver for the IP address of a domain, which is then returned so the connection can be established.\n\nHowever, public DNS works well for publicly accessible websites, but what about internal services like PostgreSQL, Redis, or RabbitMQ that should never be exposed to the internet? This is where Private DNS comes in. Private DNS operates like an internal company directory accessible only to employees or resources within a private network. For example, db.internal or redis.internal resolve only inside the private network and remain hidden from the public internet.\n\nConsider an e-commerce platform architecture with web servers, API services, PostgreSQL, Redis, and RabbitMQ. Instead of hardcoding IP addresses in the application, we use names like DATABASE_HOST = postgres.internal. This way, when infrastructure changes like instance restarts or container movement, the application remains unaffected as DNS updates automatically.\n\nIn modern dynamic infrastructure, services are highly dynamic. For instance, in Kubernetes, containers can crash, restart, or move to different IPs almost instantaneously. Hardcoding IPs would lead to operational nightmares. That's why names remain stable while IPs change. Service discovery is the solution that addresses this need.\n\nWhile DNS solves the problem of finding machines, Service Discovery addresses the need to find specific services within a distributed system. Although these concepts are related, they serve different purposes. Service discovery becomes particularly important in microservice architectures where multiple instances of services exist.\n\nImagine a system with a User Service, Order Service, Payment Service, and Notification Service, all running multiple instances. To connect to a specific Payment Service instance, the User Service needs a smarter approach than hardcoding or using static DNS. A service registry acts as an air traffic control system for services, keeping track of active services, their addresses, and health status. Each service registers itself with the registry, providing its current address. Other services can then query the registry to discover available instances of a service.\n\nNetflix pioneered this approach with their service discovery platform, Eureka. As Netflix scaled to thousands of services and millions of requests, they needed a dynamic way to discover services without manual configuration. Eureka enables services to register themselves, and other services can discover them in real-time without the burden of maintaining IP addresses manually.\n\nKubernetes takes service discovery a step further by offering built-in service discovery features. When deploying applications on Kubernetes, services can automatically discover and communicate with each other based on their names, abstracting away the complexities of dynamic IP addresses.\n\nIn summary, DNS provides the foundation for name-based communication, Private DNS extends this concept internally within private networks, and Service Discovery mechanisms like Eureka and Kubernetes built-in features enable services to dynamically discover and communicate with each other, making distributed systems more resilient and maintainable.",
  "summary": "Hey developers! 👋 Welcome back to our networking and infrastructure deep-dive series. In the previous article we learned something surprising: Two servers inside AWS, Azure, GCP, or a private datacenter can communicate without touching the public internet. No ISP. No public IP. No internet routing. Just private networking. But that raises a much bigger question. A question every backend…",
  "key_points": [
    "DNS translates human-friendly names to machine-readable IP addresses",
    "Private DNS operates as internal company directory for private networks",
    "Service discovery mechanisms like Eureka enable dynamic service discovery"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}