Глобальная проверка SRV-записей
В то время как стандартные записи A и AAAA ограничены переводом доменного имени в IP-адрес, запись SRV (Service) намного сложнее. Определенная в RFC 2782, запись SRV устанавливает стандартизированный способ определения точного имени хоста, протокола и точного номера порта для конкретных сетевых приложений. Они являются основой (backbone) обнаружения корпоративных сервисов, интенсивно используются для Microsoft Active Directory, маршрутизации SIP/VoIP, обмена мгновенными сообщениями XMPP и архитектуры серверов массовых многопользовательских игр (например, разрешение _minecraft._tcp.example.com).
Синтаксис и привязка порта (Port Binding)
Запись SRV мгновенно узнаваема по жесткой структуре форматирования. Имя записи должно начинаться с подчеркивания, обозначающего сервис, за которым следует подчеркивание, обозначающее транспортный протокол, добавленное к базовому домену (например, _sip._tls.example.com). Полученный Payload передает четыре конкретных точки данных подключающемуся клиенту: Приоритет (Priority), Вес (Weight), Целевой порт (Port) и Каноническое целевое имя хоста (Hostname). Это позволяет администраторам запускать несколько различных сервисов на одном IP-адресе с использованием нестандартных портов, не требуя от конечных пользователей запоминать и вводить номера портов в своих клиентах.
Нативный Failover и балансировка нагрузки по весам
Самой мощной особенностью записи SRV является ее нативная многоуровневая логика маршрутизации. Целое число Приоритет (Priority) действует точно так же, как в MX-записи; подключающиеся клиенты всегда будут пытаться договориться о рукопожатии (handshake) с сервером с наименьшим приоритетом в первую очередь. Это устанавливает мгновенную избыточность (failover redundancy). Если несколько записей имеют абсолютно одинаковый приоритет, запускается целое число Вес (Weight). Он действует как пропорциональный балансировщик нагрузки (Load Balancer). Если Сервер A имеет вес 75, а Сервер B — вес 25, клиентское приложение направит 75% новых подключений на Сервер A. Это позволяет инженерам интеллектуально распределять трафик по кластерам с различной аппаратной мощностью.
Почему HTTP игнорирует SRV-записи
Распространенный вопрос от младших разработчиков: почему веб-трафик (HTTP/HTTPS) не использует записи SRV для достижения нативной балансировки нагрузки. Ответ носит чисто исторический характер. К тому времени, когда записи SRV были стандартизированы, архитектурные соглашения о том, что HTTP работает строго на порту 80, а HTTPS на порту 443, были уже универсально захардкожены (hardcoded) в каждом веб-браузере. Переход веба на SRV lookups добавил бы огромный штраф к разрешению (требующий дополнительных round-trips) ради незначительной выгоды. Вместо этого HTTP полагается на балансировщики нагрузки прикладного уровня (application-layer) и IP-маршрутизацию Anycast.