Первые веб-браузеры не следуют СРВ
записи вообще, так что даже если вы можете их спроектировать, они бесполезны.
Теперь, учитывая общий процесс, чтобы узнать, что входит в любую запись, принимая СРВ
Например.
IANA является хранителем вещей, так что переходите к https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4 где можно посмотреть СРВ
что он определен в RFC 2782
Там это определяется так:
Вот формат SRV RR, код типа DNS которого равен 33:
_Service._Proto.Name TTL Класс SRV Приоритет Вес Порт Целевой порт
с тогда соответственно:
Оказание услуг
Символическое имя желаемой службы, как определено в Assigned
Номера [STD 2] или локально. Знак подчеркивания (_) добавляется перед
идентификатор службы, чтобы избежать коллизий с метками DNS, которые
встречаются в природе.
и
Прото
Символическое имя желаемого протокола с подчеркиванием
(_) добавляется в начале, чтобы предотвратить конфликты с метками DNS, которые происходят
в природе. _TCP и _UDP в настоящее время являются наиболее полезными значениями.
для этого поля, хотя любое имя, определенное Assigned Numbers или
можно использовать локально (как для Сервиса). Прото чехол
бесчувственный.
Ссылка [STD 2] — это RFC 1700, но RFC 3232 устарел, чтобы создать онлайн-базу данных возможных значений... которая снова находится в ведении IANA.
Теперь он есть: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml и обратите внимание, что это в основном то, что вы найдете в файле /и т.д./услуги
в любой Unix-системе.
Итак, возвращая ваши примеры (ваши номера портов неверны в нескольких СРВ
записи изображены хотя):
mysql
действительно определен для порта 3306
так что это допустимо как имя службы и, следовательно, в СРВ
записывать
- для порта
27017
, имя службы монгодб
, нет монго
(но уважают ли клиенты Mongo СРВ
записи?)
http
действительно определен для порта 80
так что это допустимое имя службы (и https
для порта 443)
mqtt
определяется как допустимое имя порта, для порта 1883
. Но тот же вопрос, что и выше, используют ли клиенты СРВ
записи вообще?
Обратите также внимание, что в дикой природе существуют различные СРВ
записи, не соответствующие вышеизложенному. Если их можно опубликовать, они «работают», то есть ничто не помешает их разрешению на уровне DNS, даже если они не используют зарегистрированное имя службы, как указано выше, если какое-то приложение, конечно, читает их.
Например, вы можете найти множество примеров с _sip._tls
или же _sipfederationtls._tcp
онлайн, которые оба неверны: TLS
недействительный протокол, и sipfederantiontls
недопустимое имя службы (и на самом деле слишком длинное, т.к. https://www.rfc-editor.org/rfc/rfc6335.html#section-5.1 указывает, что длина не должна превышать 15 символов). Таким образом, какой-то инструмент/пользовательский интерфейс может помешать созданию этих записей в файле зоны, а некоторые серверы имен могут отказаться их загружать, но в большинстве случаев они будут работать (если приложения их используют).