Federation is using wrong hostname even if SRV record seems correct

[soupdiver]

I lately have an issue with my instance and Federation. I have setup a SRC record point from my domain to a subdomain

Federation however tries using the wrong hostname for connections.

Federation tester: https://federationtester.matrix.org/api/report?server_name=0x23.me

{
    "WellKnownResult": {
        "m.server": "",
        "result": "No .well-known found",
        "CacheExpiresAt": 0
    },
    "DNSResult": {
        "SRVSkipped": false,
        "SRVCName": "_matrix._tcp.0x23.me.",
        "SRVRecords": [
            {
                "Target": "matrix.0x23.me.",
                "Port": 443,
                "Priority": 10,
                "Weight": 0
            }
        ],
        "SRVError": null,
        "Hosts": {
            "matrix.0x23.me.": {
                "CName": "matrix.0x23.me.",
                "Addrs": [
                    "157.90.38.13"
                ],
                "Error": null
            }
        },
        "Addrs": [
            "157.90.38.13:443"
        ]
    },
    "ConnectionReports": {},
    "ConnectionErrors": {
        "157.90.38.13:443": {
            "Message": "Non-200 response 404 from remote server"
        }
    },
    "Version": {
        "error": "contents=[52 48 52 32 112 97 103 101 32 110 111 116 32 102 111 117 110 100 10] msg=Failed to GET JSON (hostname \"0x23.me\" path \"/_matrix/federation/v1/version\"): 404 page not found\n code=404 wrapped="
    },
    "FederationOK": false
}

It seems to pickup my srv record that points to matrix.0x23.me:443 but connection goes to 0x23.me 🤔 (hostname \"0x23.me\" path \"/_matrix/federation/v1/version\"): 404 page not found\n code=404 wrapped="

dns lookup

dig @1.1.1.1 SRV _matrix._tcp.0x23.me

; <<>> DiG 9.10.6 <<>> @1.1.1.1 SRV _matrix._tcp.0x23.me
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14551
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;_matrix._tcp.0x23.me.      IN  SRV

;; ANSWER SECTION:
_matrix._tcp.0x23.me.   10800   IN  SRV 10 0 443 matrix.0x23.me.

;; Query time: 89 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Tue Dec 20 13:14:56 CET 2022
;; MSG SIZE  rcvd: 83

[reivilibre]

I think what's confusing you here is that the SRV _matrix._tcp.<delegated_hostname> record specifies the hostname <srv_hostname> of a machine that should be delegated to,

but the given server <srv_hostname> is contacted using Host: <delegated_hostname> and is expected to provide a certificate for <delegated_hostname> (!).

Since 0x23.me and matrix.0x23.me have the same IP address, you've not bought yourself anything over just using the original A record.

To do what you want, you can consider using .well-known delegation, which acts like a HTTP redirect for all federation traffic. Notably, the TLS certificate and Host header will match what the well-known hostname says, not <delegated_hostname> like in SRV delegation.

[soupdiver]

Since 0x23.me and matrix.0x23.me have the same IP address, you've not bought yourself anything over just using the original A record.

What I want to achieve is to run the server under matrix.0x23.me but use foo@0x23.me as my user.

To do what you want, you can consider using .well-known delegation, which acts like a HTTP redirect for all federation traffic

I didn't have this setup before and things worked. But... maybe something changed, not 100% sure tbh.

I tried using serve_server_wllknow but it does not seem that easy. My config:

server_name: "0x23.me"
public_baseurl: https://matrix.0x23.me/
serve_server_wellknown: true
...

Result: https://matrix.0x23.me/.well-known/matrix/server

But that seems to be the wrong way around? I suppose the file has to be served from 0x.23.me and point to matrix.0x23.me? Do I have to setup that manually or can synapse do that for me properly? Or am I confusing something?

[soupdiver]

ok, seems I fixed it with config changes on my reverse proxy thanks!