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.
来源：https://stackoverflow.com/questions/35167043/is-there-a-way-to-make-a-websocket-reachable-through-a-srv-dns-record