-
Notifications
You must be signed in to change notification settings - Fork 17
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
Comments
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... |
@olmari I'm afraid I don't understand your second paragraph, but:
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 |
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 I have a DNS SRV record created to specify this: |
@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. |
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. |
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?
The text was updated successfully, but these errors were encountered: