element-hq / element-hq/synapse

Worker-mode redis/replication connection fails on IPv6-only (AAAA-only) hosts — txredisapi resolver is IPv4-only

Open
#20,184 2 comments 0 reactions 0 assignees View on GitHub
A-Workers
Dominant language
Python
Stars
4.6k
Forks
600
Avg merge
5d 22h
Merged PRs (30d)
51

Description

### 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: https://github.com/IlyaSkriblovsky/txredisapi/issues/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

1. 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.
2. Start Synapse.
3. Observe the replication/redis connection fail with a DNS resolution error, despite `python -c "import socket; print(socket.getaddrinfo('', ))"` 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.

Contributor guide

Open the contributing guide

Research direction

Start with Synapse's worker-mode redis configuration and the txredisapi issue #161, then trace how the replication/pub-sub connection is established through Twisted. Decide whether the fix belongs in txredisapi or Synapse, and verify that an AAAA-only redis host connects successfully without breaking existing worker-mode deployments.

Written by the indexing model from the issue text.

Assessment

Tech stack
kubernetes, python, redis
Domain
backend, distributed-systems, networking
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.