Есть ли способ сделать веб-сокет доступным через запись DNS SRV?

Question

Клянусь, я погуглил это. Мне было интересно, если есть какой-либо способ подключиться к службе WebSocket путем разрешения SRV DNS-запрос. В принципе, для меня это звучит разумно, например, в ситуации, когда порт, который будет прослушивать служба, зависит от хоста, а фиксированный порт отсутствует.

Например: Сервер A прослушивает с помощью WebSocket через порт 1234. Сервер B прослушивает с помощью WebSocket через порт 1235.

Сервер NS назначает CNAME А, а CNAME к Б. Это также добавляет SRV запись, которая указывает на А и В CNAMEs, а также указывает на каждый порт.

При подключении пользователь должен подключиться к чему-то вроде srvws://websockethost скорее, чем ws://aorbcname:aorbport,

Можно ли вообще сделать такую ​​вещь? Есть ли какие-либо планы по этому поводу? Есть ли альтернатива для решения такого рода проблемы, когда мне нужно связать порты вместе с запросом DNS?

Обновление: оглядываясь вокруг, я нашел этот черновик: https://tools.ietf.org/html/draft-ibc-websocket-dns-srv-02

Но я не совсем уверен, как это интерпретировать. Это стандарт? Было ли это даже одобрено? Это просто предложение?

Answer 1

В 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. (любопытство, почему это не было реализовано, одолело меня) Я нашел это сообщение от парня, который предложил его

Я предлагал это, но после долгих обсуждений в списке рассылки я понял, что обязательное использование DNS SRV в клиентах WS нарушит слишком много предположений в мире HTTP (который обычно виден только выше уровня HTTP, а не ниже).

Существование HTTP-прокси также является большой помехой, поскольку эти прокси-серверы должны быть обновлены / модифицированы для выполнения разрешения DNS SRV на тот случай, если HTTP-запрос является рукопожатием WebSocket. Этого последнего аргумента достаточно, чтобы не требовать разрешения SRV.

Так что, хотя это звучит неплохо, люди, которые действительно понимают этот материал (и пишут стандарты для него), нашли некоторые проблемы, которые предлагали просто использовать поиск стандартных записей HTTP / A.