Service Discovery

Concepts and practical patterns for finding services in self-hosted and homelab environments

created: Sat Mar 14 2026 00:00:00 GMT+0000 (Coordinated Universal Time) updated: Sat Mar 14 2026 00:00:00 GMT+0000 (Coordinated Universal Time) #networking#service-discovery#dns

Introduction

Service discovery is the process of locating services by identity instead of hard-coded IP addresses and ports. It becomes more important as workloads move between hosts, IPs change, or multiple service instances exist behind one logical name.

Purpose

Good service discovery helps with:

  • Decoupling applications from fixed network locations
  • Supporting scaling and failover
  • Simplifying service-to-service communication
  • Reducing manual DNS and inventory drift

Architecture Overview

There are several discovery models commonly used in self-hosted environments:

  • Static DNS: manually managed A, AAAA, CNAME, or SRV records
  • DNS-based service discovery: clients query DNS or DNS-SD metadata
  • mDNS: local-link multicast discovery for small LANs
  • Registry-based discovery: a central catalog such as Consul tracks service registration and health

Discovery Patterns

Static DNS

Best for stable infrastructure services such as hypervisors, reverse proxies, storage appliances, and monitoring endpoints.

Example:

proxy.internal.example   A     192.168.20.10
grafana.internal.example CNAME proxy.internal.example

DNS-SD and mDNS

Useful for local networks where clients need to discover services such as printers or media endpoints. This works well for small trusted LAN segments, but it does not cross routed boundaries cleanly without extra relays or reflectors.

Registry-based discovery

A service catalog stores registrations and health checks. Clients query the catalog or use DNS interfaces exposed by the registry.

This is useful when:

  • Service instances are dynamic
  • Health-aware routing matters
  • Multiple nodes host the same service

Configuration Example

Consul service registration example:

{
  "service": {
    "name": "gitea",
    "port": 3000,
    "checks": [
      {
        "http": "http://127.0.0.1:3000/api/healthz",
        "interval": "10s"
      }
    ]
  }
}

DNS-SD example concept:

_https._tcp.internal.example SRV 0 0 443 proxy.internal.example

Troubleshooting Tips

Clients resolve a name but still fail to connect

  • Check whether the resolved port is correct
  • Verify firewall policy and reverse proxy routing
  • Confirm the service is healthy, not just registered

Discovery works on one VLAN but not another

  • Review routed DNS access
  • Check whether the workload depends on multicast discovery such as mDNS
  • Avoid relying on broadcast or multicast across segmented networks unless intentionally supported

Service records become stale

  • Use health checks where possible
  • Remove hand-managed DNS entries that no longer match current placements
  • Prefer stable canonical names in front of dynamic backends

Best Practices

  • Use DNS as the default discovery mechanism for stable infrastructure
  • Add service registries only when the environment is dynamic enough to justify them
  • Pair discovery with health checks when multiple instances or failover paths exist
  • Keep discovery names human-readable and environment-specific
  • Avoid hard-coding IP addresses in application configuration unless there is no realistic alternative

References