Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider adding support for Synapse 0.34 backwards-compatibility SRV records #37

Closed
richvdh opened this issue Feb 10, 2019 · 5 comments
Closed

Comments

@richvdh
Copy link
Member

richvdh commented Feb 10, 2019

Some people are using SRV records on their matrix domain as well as having a .well-known which delegates to a different domain, for compatibility with Synapse-pre-0.99, and have reported (#34) finding it confusing that the federation tester ignores that SRV record.

Maybe we could re-run the checks in a Synapse-0.34-compatibility mode?

@olmari
Copy link

olmari commented Jul 27, 2019

I agree current behaviour is kind of annoying and in some sense even misleading, as SRV and .well-known is generally considered "compliments" of each others, SRV for older stuff and .well-known for newer stuff... Add .well-known to system that has SRV already and suddenly the SRV is expected to be found where .well-known points, not to "root-domain" server..

In general this feels even more odd behaviour for "how things are supposed to work" as .well-known already should point to server and port, similar to SRV done in "old way".. .well-known and then SRV from that server address doesn't add anything to the mix AFAIK, exept all these config oddities...

@richvdh
Copy link
Member Author

richvdh commented Jul 29, 2019

@olmari I'm afraid I don't understand your second paragraph, but:

Add .well-known to system that has SRV already and suddenly the SRV is expected to be found where .well-known points, not to "root-domain" server..

This is a matter for the spec: the federation tester just follows what the spec says. If you think it's wrong, the place to discuss it is the #matrix-spec:matrix.org room or https://github.com/matrix-org/matrix-doc/issues, but given it was discussed in great detail in MSC1708, I don't think there will be much appetite for reopening the conversation.

@adrubesh
Copy link

Hello,

I believe I am experiencing this issue and would like to discuss how this is handled. From my understanding and based on https://github.com/matrix-org/synapse/blob/master/docs/federate.md both the .well-known delegration and DNS SRV records should be accepted. For instance, my server name is myservername.com however the synapse server is actually hosted at synapse.myservername.com.

I have a DNS SRV record created to specify this: _matrix._tcp.myservername.com 299 IN SRV 10 5 443 synapse.myservername.com however the federation checker say's it's failed to verify EVEN THOUGH it pulls back the correct SRV record.

@richvdh
Copy link
Member Author

richvdh commented Dec 27, 2019

@adrubesh this issue is specifically about the idea of adding a mode to the federation tester which would support the old style of federation delegation where no .well-known lookup is performed. SRV records are correctly supported by the federation tester as it stands. It's more likely that you have a different problem; I suggest checking the documentation about TLS certificates, and if you still don't understand the failure, seek help in #synapse:matrix.org.

@richvdh
Copy link
Member Author

richvdh commented Dec 27, 2019

Given that we've got this far without a backwards-compatibility mode, I don't think there's much point in adding one now. Accordingly, I'm going to close this issue.

@richvdh richvdh closed this as completed Dec 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants