💾 Archived View for bbs.geminispace.org › s › misfin › 1460 captured on 2023-07-22 at 17:08:58. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-07-10)
-=-=-=-=-=-=-
Any thoughts on making SRV records part of the spec? I think it adds a lot of flexibility for the server operator without much cost and can be pretty beneficial when your ISP does something boneheaded like block port 1958.
2023-06-03 · 7 weeks ago · 👍 ERnsTL · 1 ❤
I can see the utility of it (while at the same time marveling that an isp might think it's ok to block traffic) but hate to see a nice simple protocol gain "features".
I hate to think of this as a feature, but more of an internet-wide thing. When ISPs started blocking port 25, that killed SMTP self-hosting for lots of people at home. Imagine a world where SRV records were ubiquitous for all protocols, then "non-standard" ports would be a non-issue.
2023-06-04 · 7 weeks ago
I would also find an SRV record useful. It would add not more than a paragraph to the spec. You could mark use/lookup of the SRV record as optional for client implementations.
2023-06-08 · 6 weeks ago
I support this as well. I don’t think it adds significant complexity, and it could definitely be marked as optional.
I'm curious how you think making this optional would improve things rather than add confusion. If it were a mandatory part of a spec, then any client would be able to look up a server regardless of the port it's running on. If it's optional and I need to run a server on a non-default port for one reason or another, then a client that supports SRV will load the site just fine, but a client that doesn't will probably leave a user confused when his buddy says it works just fine.
2023-06-13 · 6 weeks ago
I also think SRV records could be used for multi-hosting in a sane way. If I have an account on a server with many other users and I don't have root access, then I'm essentially forced to use a non-default port for any server process I want to run. If I run a server for a protocol that requires SRV records to be defined, then many users could run their own processes on arbitrary ports, each with their own domain CNAMEs and SRVs with no problem.
@winduptoy good point. I guess what I mean is no SRV record is necessary if one wants to use the default port. It shouldn’t really be an optional feature for clients though, that would be confusing.