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

CNAME should be explicitly allowed or disallowed in server name resolution spec #606

Closed
tulir opened this issue Apr 13, 2020 · 3 comments · Fixed by #1376
Closed

CNAME should be explicitly allowed or disallowed in server name resolution spec #606

tulir opened this issue Apr 13, 2020 · 3 comments · Fixed by #1376
Labels
A-S2S Server-to-Server API (federation) clarification An area where the expected behaviour is understood, but the spec could do with being more explicit

Comments

@tulir
Copy link
Member

tulir commented Apr 13, 2020

Each step in the "Resolving server names" spec tells you to "resolve the IP address using AAAA or A records", which doesn't make it clear whether or not CNAME records are allowed.

If they're not allowed, Synapse should be fixed not to allow them.

@turt2live
Copy link
Member

Reading it word for word, it would indeed be a Synapse issue as the MSC was not clear: matrix-org/matrix-spec-proposals#1708

However, it's logical to assume that CNAME is supported as it does eventually point to an A or AAAA record.

@turt2live turt2live added clarification An area where the expected behaviour is understood, but the spec could do with being more explicit A-S2S Server-to-Server API (federation) labels Apr 14, 2020
@lub
Copy link
Contributor

lub commented Apr 20, 2020

I don't know if you are aware, but SRVs are not allowed to have a CNAME as target. I guess this is only about .well-known and server_name?

Target
The domain name of the target host. There MUST be one or more
address records for this name, the name MUST NOT be an alias (in
the sense of RFC 1034 or RFC 2181).

https://tools.ietf.org/html/rfc2782

@Thulinma
Copy link

Since there hasn't been any movement on this issue for over a year, I figured I'd add an outsider's point of view:

It would indeed make sense for CNAME's to be allowed (for .well-known and server_name), as that is how the larger internet functions in general. However, reading the current spec, I would understand it as them to specifically not be allowed.

In my personal opinion as somebody that has implemented numerous specifications/protocols/servers, this is extremely jarring and confusing and I would heavily recommend clarifying the spec to explicitly allow CNAME as well. Or, even better: word it something to the extend of "using the standard hostname resolution of the operating system", so that potential future changes to DNS are automatically accounted for and followed in a logical/consistent manner.

Especially since Synapse already follows CNAME records and following them inside a browser cannot be avoided (!), it would make sense to not let this rest for even longer and fix up the wording to be in-line with both current behavior of the reference implementation and the capabilities of modern browsers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-S2S Server-to-Server API (federation) clarification An area where the expected behaviour is understood, but the spec could do with being more explicit
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants