Synapse fails to make DNS query for its own hostname when attempting invite via 3PID

[daudo]

As discussed in matrix-org/synapse#9475, synapse has recently introduced the ip_range_blacklist parameter, disabling all kinds of communications with IP ranges defined there.

According to https://github.com/matrix-org/synapse/blob/e9f2ad86034d27068941379f678e19bf280ed308/docs/sample_config.yaml#L212 it defaults to:

#ip_range_blacklist:
#  - '127.0.0.0/8'
#  - '10.0.0.0/8'
#  - '172.16.0.0/12'
#  - '192.168.0.0/16'
#  - '100.64.0.0/10'
#  - '192.0.0.0/24'
#  - '169.254.0.0/16'
#  - '192.88.99.0/24'
#  - '198.18.0.0/15'
#  - '192.0.2.0/24'
#  - '198.51.100.0/24'
#  - '203.0.113.0/24'
#  - '224.0.0.0/4'
#  - '::1/128'
#  - 'fe80::/10'
#  - 'fc00::/7'
#  - '2001:db8::/32'
#  - 'ff00::/8'
#  - 'fec0::/10'

This effectively disables synapse from talking to nameservers with IPs in those ranges, leading to synapse unable to find it's own name:

twisted.internet.error.DNSLookupError: DNS lookup failed: no results for hostname lookup: matrix.example.com.

[spantaleev]

How do you reproduce it?

The nameserver in the matrix-synapse container (cat /etc/resolv.conf) is Docker's internal DNS (127.0.0.11), which does match the first entry ('127.0.0.0/8') in ip_range_blacklist.

[daudo]

if you follow the discussion in the Synapse issue, it appears now that the DNS queries are not blocked actually but instead answers that are within the ip_range_blacklist are filtered, that's why synapse doesn't find itself. The error message is misleading.

matrix-org/synapse#9475 (comment)

What I was trying to do initially was to set up go-neb and just invite the bot user in some test room. Inviting my very own bot user using 3PID failed with the error message above.

[spantaleev]

That go-neb problem is interesting. The same should happen if you try to message any other user (or bridge) on your homeserver, right? Yet, we don't have failure on such a massive scale, as far as I know.

[daudo]

yes, it obviously hasn't hit the masses yet :)

But if you look at the issue, almost everyone there is running their installation based on your ansible scripts, so I guess there is some common determinant.

I have since mitigated the issue by excluding my homeserver's internal IP net from the blacklisted address ranges.