Matrix does not support SVCB DNS records for homeserver discovery

[lindsayschm]

Description

I am running a homeserver behind a dynamic IP, and run my own BIND9 DNS servers with RFC2136 updates to track said dynamic IP. CNAMEs are not allowed to be used for the apex records of domains (and SRV records aren't allowed to point to CNAMEs, which is its own problem). The IETF is working on a new DNS record standard, SVCB/HTTPS, and this record type has been adopted by a bunch of the big names (firefox, chrome, BIND9, apple). SVCB records are effectively a replacement for SRV records, and fix the issue of CNAMEs not being allowed for apex records. As such, I have implemented SVCB records for both my apex domains and also for the 8448 redirection (what would otherwise be a SRV record) in my zone records.

Attempts to log in to the homeserver work just fine. Attempts to access it from other homeservers via DNS and public IP fail -- as far as I can tell, because it doesn't recognize the SVCB record and therefore won't follow it.

While using dynamic IPs may not be the best idea for any web services, the prevalence of ISPs refusing to issue static IPs to residential users is a large issue and we are as such relegated to said dynamic IPs. SVCB records fix this issue.

When will Synapse support them?

Steps to reproduce

• have dynamic IP
• run own BIND9 servers
• use SVCB record in BIND9 zone to setup apex domain on dynamic IPs
• use SVCB record in BIND9 zone to point matrix to correct port
• set up homeserver
• have somebody else try to talk to a user on that homeserver

Homeserver

glitchiest.town

Synapse Version

1.65.0

Installation Method

No response

Platform

Ubuntu Server 22.04 on QEMU on Proxmox VE
BIND9

Relevant log output

(if I can get logs from other homeserver admins, I will edit and post them here)

Anything else that would be useful to know?

No response

[clokep]

For references, this seems to be https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-10 or https://github.com/MikeBishop/dns-alt-svc.

The server discovery is part of the specification (see resolving server names). So I think this is a question for the Matrix spec, not Synapse.

I'm unsure, but I suspect using .well-known delegation would fix your issue. You could use matrix.your.host, which can be a standard CNAME (since it isn't the APEX record) to wherever you'd like to run your homeserver. The only caveat is you need to host a single (static) file on the APEX.

Regardless, I'm going to move this to the matrix-spec repo as this isn't an implementation question (yet).

[richvdh]

personally, I'd like to drop support for SRV records, since they cause a lot of confusion and I have yet to hear of a case where .well-known delegation is insufficient. This seems to be going in the opposite direction.

[lindsayschm]

@clokep thank you for the response and for getting this to the right place. (And yes, that first spec document at least looks correct)

I do in fact have a well known at the apex landing on the webserver. The problem comes from the fact that the apex DNS record is not a static IP so even though it has that well known, it's still not finding it due to not following the SVCB record.

@richvdh I can't really speak to removing SRV records altogether besides that they are a good backup. Even if SRV record support was removed, the SVCB support would still be needed for servers to find the IPs of those apex domains --- and their webservers.

So my request, regardless of whether the 8448-SRV-record support is dropped, is that Matrix be able to follow SVCB records to their conclusion like CNAMEs. What would this take?

[richvdh]

Yes ok, this seems to be orthogonal to SRV records.

What would this take?

As a first step, it would take writing a spec proposal (https://github.com/matrix-org/matrix-spec-proposals) explaining why this would be a valuable extension, and seeking community feedback on it.

[neilalexander]

personally, I'd like to drop support for SRV records, since they cause a lot of confusion and I have yet to hear of a case where .well-known delegation is insufficient

It would be insufficient in the case that we ever manage to replace HTTP+JSON on the federation API with something else not-HTTP+JSON, which I really hope we do eventually.