Description
Synapse's redis-based replication/pub-sub (redis: config, worker-mode deployments) can't connect to a redis/valkey host on an IPv6-only network — i.e. a host whose DNS name resolves only via AAAA, with no A record at all. The connection fails with a DNS lookup error before a socket is ever opened, even though the host is reachable over IPv6 and socket.getaddrinfo() resolves it correctly from the same environment.
Root cause is in txredisapi, not Synapse: it connects via Twisted's legacy reactor.connectTCP(), which — absent an explicitly installed custom resolver — resolves hostnames through Twisted's default BlockingResolver, whose implementation is a direct socket.gethostbyname() call. That function only ever queries A (IPv4) records; it has no AAAA/IPv6 awareness regardless of platform. Full trace (both the txredisapi and Twisted source) and a suggested fix (migrate to Twisted's HostnameEndpoint, which resolves via getaddrinfo) is filed upstream: IlyaSkriblovsky/txredisapi#161
Scope: this only affects worker-mode deployments that actually enable redis: for replication — a single-process/monolith Synapse never touches this code path at all, since redis is entirely optional there.
Steps to reproduce
- Run Synapse in worker mode on an IPv6-only network (no IPv4 anywhere), with
redis.host pointing at a redis/valkey/compatible server whose DNS name has only an AAAA record.
- Start Synapse.
- Observe the replication/redis connection fail with a DNS resolution error, despite
python -c "import socket; print(socket.getaddrinfo('<redis-host>', <port>))" resolving the same name correctly from the same environment.
Homeserver
N/A (general deployment issue, not homeserver-specific)
Synapse Version
current (matrix-synapse chart / element-hq/synapse, txredisapi as currently pinned)
Installation Method
Other (Kubernetes / Helm)
Platform
IPv6-only network — no IPv4 addresses assigned anywhere in the deployment environment.
Relevant log output
No response — this is a connection-establishment failure at the DNS layer; see the linked txredisapi issue for the exact traceback shape (DNSLookupError via Twisted's BlockingResolver.getHostByName).
Anything else that would be useful to know?
Given IPv6-only deployments are only going to become more common, and this is a real gap for anyone running worker-mode Synapse in one: worth deciding whether the fix should land as a txredisapi patch (matching the precedent set by #19238 → txredisapi's username-auth patch) or whether it's worth reconsidering the dependency itself — happy to help with either.
Description
Synapse's redis-based replication/pub-sub (
redis:config, worker-mode deployments) can't connect to a redis/valkey host on an IPv6-only network — i.e. a host whose DNS name resolves only via AAAA, with no A record at all. The connection fails with a DNS lookup error before a socket is ever opened, even though the host is reachable over IPv6 andsocket.getaddrinfo()resolves it correctly from the same environment.Root cause is in
txredisapi, not Synapse: it connects via Twisted's legacyreactor.connectTCP(), which — absent an explicitly installed custom resolver — resolves hostnames through Twisted's defaultBlockingResolver, whose implementation is a directsocket.gethostbyname()call. That function only ever queries A (IPv4) records; it has no AAAA/IPv6 awareness regardless of platform. Full trace (both the txredisapi and Twisted source) and a suggested fix (migrate to Twisted'sHostnameEndpoint, which resolves viagetaddrinfo) is filed upstream: IlyaSkriblovsky/txredisapi#161Scope: this only affects worker-mode deployments that actually enable
redis:for replication — a single-process/monolith Synapse never touches this code path at all, since redis is entirely optional there.Steps to reproduce
redis.hostpointing at a redis/valkey/compatible server whose DNS name has only an AAAA record.python -c "import socket; print(socket.getaddrinfo('<redis-host>', <port>))"resolving the same name correctly from the same environment.Homeserver
N/A (general deployment issue, not homeserver-specific)
Synapse Version
current (matrix-synapse chart / element-hq/synapse, txredisapi as currently pinned)
Installation Method
Other (Kubernetes / Helm)
Platform
IPv6-only network — no IPv4 addresses assigned anywhere in the deployment environment.
Relevant log output
No response — this is a connection-establishment failure at the DNS layer; see the linked txredisapi issue for the exact traceback shape (
DNSLookupErrorvia Twisted'sBlockingResolver.getHostByName).Anything else that would be useful to know?
Given IPv6-only deployments are only going to become more common, and this is a real gap for anyone running worker-mode Synapse in one: worth deciding whether the fix should land as a txredisapi patch (matching the precedent set by #19238 → txredisapi's username-auth patch) or whether it's worth reconsidering the dependency itself — happy to help with either.