0

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?

Community
  • 1
  • 1
Matteo Monti
  • 8,362
  • 19
  • 68
  • 114

1 Answers1

1

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.

Community
  • 1
  • 1
Michael B
  • 11,887
  • 6
  • 38
  • 74
  • Thank you for the detailed answer! However, it is unclear to me what do you mean by "there is no reason why you can't". I mean, of course I could be able to do such a thing with a proprietary client, but is there any way to do it in a web browser? I guess I should do the dns resolution step on my own, and that isn't allowed by browsers, am I right? Would there be other reasonable solutions of this kind? – Matteo Monti Feb 03 '16 at 09:27
  • @MatteoMonti I wrote this off the back of the DNS tag, from a DNS angle I can tell you what it does, why it does it and probably find the original discussion about the reasons for doing it. When it comes to implementing, I usually stumble around and pass it along to people who actually understand that stuff - You are probably best posting another, more explicit question about how to look up a WS service to whatever technology you are using clientside. (or add the tag to this one) – Michael B Feb 03 '16 at 10:48