有没有办法通过SRV DNS记录访问Websocket？ [英] Is there a way to make a websocket reachable through a SRV DNS record?

问题描述

我发誓我这么干我想知道是否有任何方法通过解决一个 SRV DNS查询来连接到WebSocket服务。原则上，对我来说听起来是合理的，例如，在服务正在收听的端口取决于主机和没有固定端口的情况。

例如：
服务器在端口1234上监听一个WebSocket。
服务器B在端口1235上侦听一个WebSocket。

服务器NS向A分配一个 CNAME ，将一个 CNAME 分配给B.它还添加了一个 SRV 条目指向A和B的 CNAME s，并指向每个端口。

连接时，用户应该连接到一些类似 srvws：// websockethost 而不是 ws：// aorbcname：aorbport 。

甚至可以做这样的事情吗？有没有计划呢？有什么办法可以解决这种问题，在那里我需要与DNS查询一起传送端口？

更新：环顾四周发现了这个草案： https://tools.ietf.org/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草案 WebSocket协议的DNS SRV资源记录具有以下

SRV将是许多人的完美选择
[...]这将是完全可选的admin和user
透视。网站所有者可以决定使用SRV。
只是需求，当然，WS客户端支持它

所以没有技术规范，当然没有理由你不能/不应该。这个想法已被提出并被允许死亡，因为如果要使用SRV记录来查找完全在协议中的WS服务，最终取决于您。

在我看来，这将解决一些问题。

已编辑添加

在IETF留言板上进行了更多的挖掘之后。 （好奇，为什么没有实现得到我的更好）我发现来自提出这个消息的人

我在提出它，但经过长时间的讨论，我在maillist '$ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $
$ b

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://tools.ietf.org/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屋！