Кратко

  • DNS SRV позволил администратору домена публиковать для конкретной службы и транспорта несколько целей, их порты, основные и резервные уровни и статическое предпочтение между хостами одного уровня.
  • Priority и Weight выражают разные решения. Клиент сначала пробует достижимый уровень с наименьшим числом, а лишь внутри него строит взвешенный случайный порядок.
  • Запись не доказывает исправность и идентичность. Клиент ещё должен разрешить каноническую цель, подключиться к объявленным транспорту и порту и проверить ответившее приложение.

Когда место службы хранилось в привычках клиента

Ранний DNS связывал имя хоста с адресом. Остальное приложение добавляло из соглашения: известный порт, локальную таблицу /etc/services или точное имя сервера из документации оператора. Публичное имя, хост, порт и резервный план сливались в одно предположение.

RFC 2052 предложил в октябре 1996 года экспериментальную запись для другого вопроса: где находится служба внутри домена? Ответ мог перечислить цели с приоритетами, весами и портами.

В феврале 2000 года RFC 2782 заменил документ как Proposed Standard. Он позволял с меньшими усилиями переносить службу между хостами, использовать несколько серверов и отделять основные от резервных. IANA и сейчас регистрирует SRV как тип DNS 33, Server Selection.

Имя запроса разделило службу, транспорт и домен

Клиент LDAP через TCP в example.com спрашивает _ldap._tcp.example.com. Левые метки называют службу и транспорт, остальная часть — административный домен. RFC 2782 добавил подчёркивания, чтобы метаданные не сталкивались с обычными DNS-именами, и уточнил алгоритм веса.

RFC 6335 позже объединил процедуры имён служб и портов. Зарегистрированное имя может применяться в SRV даже без назначенного порта. Регистрация координирует строку, но не одобряет продукт или трафик.

RFC 8552 создал в 2019 году реестр глобальных DNS-узлов с подчёркиванием. RFC 8553 приспособил использующие SRV спецификации к этой модели, сохранив развёрнутую практику. Приём против коллизий стал проверяемой границей распределения имён.

Приоритет не является весом

SRV содержит Priority, Weight, Port и Target.

Priority задаёт уровни отказоустойчивости. Клиент обязан попытаться достичь цель с наименьшим числом. Более высокий уровень — не равный сервер с меньшей нагрузкой, а резерв после отказа предпочтительного уровня.

Weight действует только среди записей одной Priority. Клиент суммирует веса, выбирает равномерное случайное число, находит цель по накопленной сумме, удаляет её и повторяет. Зона публикует относительный уклон; клиент создаёт порядок. Нулевой вес при наличии положительных не означает абсолютный запрет: алгоритм оставляет очень малую вероятность.

В примере RFC 2782 два хоста Priority 0 имеют веса один и три. На множестве независимых первых выборов второй стремится получить три четверти. Два хоста Priority 1 появляются только при недоступности первой пары. Одна выдача не обещает точное соотношение.

Weight не является телеметрией живой нагрузки. CPU, очередь и задержка меняются быстрее DNS-cache. Погоня за ними короткими TTL увеличила бы нагрузку DNS и ослабила надёжность. Поле выражает относительно стабильную ёмкость или качество соединения.

Port переносит ещё одно знание в DNS. Он может совпадать с назначенным номером, но не обязан. Служба может сменить порт без обновления локальной таблицы каждого клиента.

Target должен иметь адресные записи и не может быть alias. Клиент использует A/AAAA из Additional Data или запрашивает их отдельно. SRV заканчивается каноническим хостом и не скрывает цепочку CNAME или DNAME.

Отсутствие и явная недоступность различаются

Единственный Target . прямо объявляет, что эта служба в домене недоступна. Домен и другие службы могут существовать.

При отсутствии пригодного SRV первоначальная процедура запрашивала адрес домена и пробовала старое соглашение. RFC 2782 признавал нереальность одновременного обновления всех клиентов. Разумные адреса поддерживали старые программы, но чисто резервный хост не следовало показывать там как предполагаемый основной.

Совместимость была операторским решением. Она сохраняет доступ и может обходить Priority и Port. Её удаление выравнивает политику и способно отключить legacy software.

Опубликованный кандидат не доказывает службу

Клиент разбирает весь RRset, группирует Priority, упорядочивает Weight, разрешает адреса и пробует транспорт, адрес и порт. Подлинный DNS-ответ доказывает, что опубликовала DNS-authority. Он не доказывает здоровье процесса, идентичность приложения, согласие хоста или общее владение.

Более выразительная запись расширяет ущерб ложных данных. Поддельщик DNS может указать неверный порт вместе с именем и адресом. Домен способен назвать чужой хост и направить к нему нежелательный трафик. Точные порты усложняют фильтрацию и требуют сотрудничества DNS- и сетевых операторов.

Применимость тоже ограничена. Спецификация приложения должна разрешить SRV, определить символическое имя и рассмотреть безопасность. Протокол придаёт смысл, домен публикует, клиент исполняет, а цель всё ещё доказывает реальную службу.

Источники и границы доказательств

Закрытый набор включает RFC 2052, RFC 2782, RFC 6335, RFC 8552, RFC 8553 и параметры DNS IANA. Они подтверждают контракт и эволюцию, но не нынешнее внедрение, выигрыш задержки, соответствие продуктов или здоровье живой службы.

SRV позволил имени пережить один хост и порт, не передав DNS полномочия над соединением и проверкой приложения.