Multicast DNS (mDNS)

mDNS eliminates the need for manual network configuration or a dedicated DNS server. Devices automatically configure their own hostnames (typically hostname.local) and resolve the names of other devices by sending queries to a well-known multicast address (224.0.0.251 for IPv4, FF02::FB for IPv6). This enables plug-and-play functionality for printers, file shares, and IoT devices, where devices discover each other as soon as they join the network.

Instead of sending a DNS query to a unicast server, an mDNS client sends its query to the multicast address. All devices on the local link that are listening for mDNS traffic receive the query. The device that owns the requested name responds with its IP address via a multicast response. This ensures all listening devices update their caches simultaneously, maintaining network consistency. The protocol operates on UDP port 5353 and is designed not to propagate beyond a single network segment (TTL is typically set to 1).

mDNS uses a dedicated, reserved top-level domain: .local. This namespace is guaranteed not to conflict with globally routable DNS names. When a device needs to resolve printer.local, it sends an mDNS query for that exact name. The authoritative device responds with its IP address. This provides a clear separation between local, auto-configured services and internet-based services resolved via conventional DNS.

mDNS is often paired with DNS-SD, defined in RFC 6763, to advertise and discover services, not just hostnames. DNS-SD uses standard DNS record types:

• PTR records to list available service types (e.g., _http._tcp.local).
• SRV records to point to the hostname and port of a specific instance.
• TXT records to provide optional metadata (e.g., version, path). Together, mDNS and DNS-SD allow a client to browse for "available web servers" and then resolve the connection details for a chosen instance.

Before claiming a hostname like laptop.local, an mDNS device performs a probing sequence. It sends multicast probes to see if any other device responds to that name. If a conflict is detected, the device must choose a different name or the human user is alerted. This prevents duplicate names on the network. Once a name is claimed, the device periodically announces it via multicast announcement packets to defend its claim and refresh neighbor caches.

To prevent stale information, all mDNS responses include a Time-To-Live (TTL) value in the DNS record, typically 120 seconds. Devices cache the records they hear. If a device shuts down gracefully, it sends a multicast goodbye packet (a response with a TTL of 0) to inform others to flush its records immediately. If it fails ungracefully, other devices' caches will expire the records naturally based on the TTL, ensuring the network self-heals.

DNS-Based Service Discovery (DNS-SD) is a protocol that uses standard DNS record types (SRV, TXT, PTR) to advertise and discover services on a network. It is often paired with mDNS to create a complete zero-configuration solution.

• SRV Records specify a service's hostname and port.
• TXT Records provide key-value metadata about the service (e.g., version, capabilities).
• PTR Records enable browsing for services of a given type.

Example: A printer advertises itself as _ipp._tcp.local via DNS-SD over mDNS, allowing computers to automatically discover and install it.

A service registry is a centralized or decentralized database that tracks the network locations and metadata of available agents or services in a distributed system. It is the authoritative source for service discovery.

• Centralized Registries: Single source of truth (e.g., etcd, Consul). Provide strong consistency.
• Decentralized Registries: Peer-to-peer, like mDNS. Favors availability and partition tolerance.
• Core Functions: Maintain a list of live instances, their IP addresses, ports, health status, and metadata tags.

A lease mechanism grants an agent a time-bound registration in a service registry. The agent must periodically renew this lease by sending a heartbeat signal. This pattern is critical for maintaining an accurate view of system health.

• Heartbeat Failure: If heartbeats stop, the registry assumes the agent has failed and automatically deregisters it after the lease expires.
• Prevents Stale Entries: Ensures the registry does not contain entries for crashed or disconnected agents.
• Contrast with mDNS: mDNS uses periodic multicast announcements instead of a centralized lease, but serves a similar liveness-checking purpose.

The sidecar pattern is a deployment model where a helper container runs alongside a primary application container to provide ancillary services like service discovery, health checks, and observability.

A service mesh (e.g., Istio, Linkerd) extends this concept across an entire application network. It provides:

• Transparent Service Discovery: Proxies (sidecars) handle registry lookups and routing.
• Load Balancing: Distributes traffic among healthy service instances.
• Security: Manages mutual TLS and authentication.
• Observability: Collects metrics, logs, and traces for all service-to-service communication.

These are two fundamental patterns for how a service consumer locates a provider.

• Client-Side Discovery: The client (or its library) queries the service registry directly, obtains a list of available instances, and uses a load-balancing algorithm to select one. Example: A microservice using the Eureka client library.
• Server-Side Discovery: The client sends a request to a stable endpoint (like an API Gateway or Load Balancer). This intermediary component queries the registry and routes the request. Example: A Kubernetes Service, where the kube-proxy handles discovery and routing to Pods.

Capability advertisement is the act of an agent publishing a structured description of its functions, interfaces, and supported protocols to a registry. Capability query is the inverse: a request to find agents matching specific functional requirements.

• Advertisement Content: Includes API schemas (OpenAPI/GraphQL), supported task types, input/output formats, and non-functional Service-Level Agreement (SLA) attributes like max latency.
• Query Mechanism: Allows for dynamic, intent-based discovery. An agent can search for "an agent that can translate Spanish to English with <100ms latency" rather than just a hostname.
• mDNS/DNS-SD Implementation: Uses DNS TXT records for simple key-value metadata advertisement.