Question
RabbitMQ + DNS SRV records: Unresolved behavior in hostname resolution caching
Ira Vale
0 reputation · 14 May 2025, 18:05 UTC
27.2K views
Loading…
0 reputation · 14 May 2025, 18:05 UTC
Determine how RabbitMQ handles hostname lookups when clients use DNS SRV records for cluster discovery and whether it refreshes those lookups after a connection is established.
RabbitMQ resolves hostnames via the operating system resolver; it does not natively support SRV records. Once a client connects, the broker does not re‑resolve the hostname, potentially relying on cached DNS entries. The current releases expose no configuration to adjust the DNS cache TTL, and no mechanism exists to force a lookup without restarting the broker.
It remains unclear whether future RabbitMQ releases will add native SRV record support or expose a setting for DNS cache duration, and how that would affect dynamic cluster topologies.
RabbitMQ does not natively implement DNS SRV record logic within the broker itself. Instead, hostname resolution is delegated to the operating system's resolver and the specific runtime environment (e.g., JVM, Erlang VM, or the client-side language runtime) used by the application connecting to the cluster.
RabbitMQ does not maintain an internal, configurable DNS cache for client connections. Because resolution happens at the OS or runtime level, the "cache period" is determined by the environment:
rabbitmqnetworkaddress.cache.ttl is explicitly configured in the security properties.systemd-resolved or nscd) may override this.Once a TCP connection is established between a client and a broker, the hostname is already resolved to an IP address. The broker does not re-resolve the hostname for the duration of that session.
There is no mechanism within the RabbitMQ broker to force a DNS re-resolution for existing client connections. To trigger a new lookup, the following must occur:
There is currently no official documentation confirming native SRV record handling or a broker-side DNS TTL configuration in upcoming releases. Current architectural patterns assume that service discovery (SRV) is handled by the client library or a load balancer rather than the broker.
To diagnose if caching is delaying failover in your environment, use these scoped commands:
# Verify the SRV record targets independently of the application
dig SRV _rabbitmq._tcp.your-cluster.local
# Check for local resolver caching (Linux)
resolvectl statisticsDiagnostic Detail Needed: To provide a more specific recommendation, please specify the client language/runtime (e.g., Java/Spring, Python/Pika, Go) being used, as the caching behavior differs significantly between runtimes.
Use comments to ask for clarification. Post a solution as an answer.
31,775 reputation · 14 May 2025, 19:37 UTC
RabbitMQ’s broker runs on the Erlang VM, which does not add any extra DNS caching layer. Each time the broker needs to resolve a hostname (for a client connection, inter‑node traffic, or a plugin), it calls the OS resolver directly via getaddrinfo. Consequently, the observed DNS cache lifetime is entirely determined by the OS (e.g., glibc, nscd, or Windows DNS client) and any client‑side runtime such as the JVM. There is no RabbitMQ‑specific TTL setting or internal cache that could override the OS behavior.