有没有办法通过 SRV DNS 记录访问 websocket? [英] Is there a way to make a websocket reachable through a SRV DNS record?
问题描述
我发誓我用谷歌搜索了这个.我想知道是否有任何方法可以通过解析 SRV DNS 查询来连接到 WebSocket 服务.原则上，这对我来说听起来很合理，例如，在服务要侦听的端口取决于主机并且没有固定端口的情况下.
例如:服务器 A 在端口 1234 上使用 WebSocket 进行侦听.服务器 B 在端口 1235 上使用 WebSocket 进行侦听.
Server NS 为 A 分配一个 CNAME，为 B 分配一个 CNAME.它还添加了一个指向 A 和 B 的 SRV 条目CNAMEs，也指向每个端口.
连接时，用户应该连接到类似 srvws://websockethost 而不是 ws://aorbcname:aorbport 的东西.
有没有可能做这样的事情?有没有这方面的计划?有没有其他方法可以解决此类问题，我需要在进行 DNS 查询的同时进行端口通信?
更新:环顾四周，我发现了这个草案:https://datatracker.ietf.org/doc/html/draft-ibc-websocket-dns-srv-02
但我不太确定如何解释这一点.这是标准吗?这甚至被批准了吗?这只是一个提议吗?
在 RFC 2782 一个 DNS用于指定服务位置的 RR (DNS SRV) 声明
<块引用>目前，您必须知道服务器的确切地址才能联系它，或广播一个问题.
<块引用>
SRV RR 允许管理员将多个服务器用于单个域，可以毫不费力地将服务从主机转移到主机，并且将一些主机指定为服务的主服务器，而将其他主机指定为备份.
SRV RR 的格式是
<块引用>_Service._Proto.Name TTL 类 SRV 优先权重端口目标
您不能使用 SRV 记录指向 WS 并不是技术原因.正如您所指出的，它一直是 IETF 草案的主题.这似乎没有更进一步，尽管其原因尚不清楚 历史 它似乎已与 RFC 6455 合并WebSocket 协议有一个讨论 关于包含 IETF 草案 DNS SRV 资源记录具有以下内容的 WebSocket 协议
<块引用>SRV 将是许多人的完美选择[...] 管理员和用户完全可以选择看法.网站所有者可以决定是否使用 SRV.这当然，只要求 WS 客户端支持它
因此，虽然没有技术规范，但您当然没有理由不能/不应该.这个想法已经被提出并被允许死亡，因为最终是否要使用 SRV 记录来查找完全符合协议的 WS 服务取决于您.
在我看来，它可以解决很多问题.
编辑添加
在 IETF 留言板上进一步挖掘之后.(好奇为什么它没有实施让我更好)我发现 这条消息来自提议它的人
<块引用>我是提议的，但在邮件列表中经过长时间的讨论后我已经了解在 WS 客户端中强制使用 DNS SRV 会破坏太多HTTP 世界中的假设(通常只在 HTTP 层之上看到而不是下面).
<块引用>
HTTP 代理的存在也是一个很大的障碍，因为那些应升级/修改代理以执行 DNS SRV解析只是，以防 HTTP 请求是 WebSocket 握手.最后一个论点足以不强制要求进行 SRV 解析.
虽然这听起来是个好主意，但真正了解这些东西(并为其编写标准)的人发现了一些建议仅使用标准 HTTP/A 记录查找的问题.
I swear I googled this. I was wondering if there is any way to connect to a WebSocket service by resolving a SRV DNS query. In principle, this sounds reasonable to me, e.g., in a situation where the port where the service is going to be listening depends on the host and there is not a fixed port.
For example: Server A listens with a WebSocket on port 1234. Server B listens with a WebSocket on port 1235.
Server NS assigns a CNAME to A, and a CNAME to B. It also adds a SRV entry that points to A's and B's CNAMEs, and also points to each port.
When connecting, an user should then connect to something like srvws://websockethost rather than ws://aorbcname:aorbport.
Is it even possible to do such a thing? Is there any planning at all about this? Is there any alternative to solve this kind of problem, where I need to communicate ports along with the DNS query?
Update: looking around I found this draft: https://datatracker.ietf.org/doc/html/draft-ibc-websocket-dns-srv-02
But I am not really sure how to interpret this. Is this a standard? Was this even approved? Is this just a proposal?
In RFC 2782 A DNS RR for specifying the location of services (DNS SRV) it states
Currently, one must either know the exact address of a server to contact it, or broadcast a question.
The SRV RR allows administrators to use several servers for a single domain, to move services from host to host with little fuss, and to designate some hosts as primary servers for a service and others as backups.
The format of a SRV RR is
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
There is no technical reason that you couldn't use a SRV record to point to a WS. As you point out it has been the subject of an IETF draft. That doesn't appear to have gone any further, though the reasons aren't clear from its history it does appear to have been merged with RFC 6455 The WebSocket Protocol There is a discussion concerning the inclusion of IETF draft DNS SRV Resource Records for the WebSocket Protocol that has the following
SRV would be a perfect choice for many people [...] It would be fully optional from the admin and user perspective. The website owner could decide to use SRV or not. The only requeriment, of course, os that WS clients support it
So while there is no technical specification, there is certainly no reason why you can't / shouldn't. The idea has been proposed and allowed to die because ultimately it is up to you if you want to use a SRV record to find a WS service that is perfectly within protocol.
And in my opinion, it would solve a number of problems.
Edited to add
After some more digging around on the IETF message boards. (curiosity as to why it wasn't implemented got the better of me) I found this message from the guy who proposed it
I was proposing it, but after long discussions in the maillist I've understood that mandating DNS SRV in WS clients would break too much assumptions in HTTP world (which commonly just sees above HTTP layer and not below).
The existence of HTTP proxies is also a big handicap since those proxies should be upgraded/modified in order to perform DNS SRV resolution just in case the HTTP request is a WebSocket handshake. This last argument is enough to not mandate SRV resolution.
So while it sounds a good idea, the people who really understand this stuff (and write the standards for it) found some issues that suggested simply using standard HTTP / A record look ups.
这篇关于有没有办法通过 SRV DNS 记录访问 websocket?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
