Кратко

  • Меньшая SvcPriority означает предпочтение только среди пригодных записей. Сначала клиент исключает повреждённые, противоречивые и несовместимые варианты; неизвестный обязательный ключ способен лишить права выбора формально первый узел.
  • AliasMode делегирует поиск сервиса, не меняя origin. ServiceMode связывает цель и параметры, однако IP-hint, объявленный ALPN и даже проверенный DNS остаются входными данными; A/AAAA, сертификат исходного имени, согласованный ALPN и ответ приложения дают отдельные доказательства.

Первый номер за пределами списка

Представим origin с двумя HTTPS-записями ServiceMode. Приоритет 1 ведёт на новую edge-площадку и помечает экспериментальный параметр как mandatory. Приоритет 2 оставляет старую площадку с параметрами, понятными установленным клиентам. Панель называет первый узел предпочтительным.

Для клиента без нового расширения этот узел вообще не кандидат. RFC 9460 требует игнорировать ServiceMode, если клиент не понимает все обязательные ключи. Он переходит к приоритету 2 и может успешно соединиться. Порядок не перевёрнут: пригодность была определена раньше предпочтения.

Это аналитический пример, а не сообщение об отдельном браузере или CDN. Владелец DNS может составить варианты соединения, но не способен публикацией добавить всем клиентам поддержку, открыть сетевой порт, заставить сервер выбрать протокол или превратить сертификат провайдера в удостоверение исходного сервиса.

Два режима и две границы полномочий

RFC 9460 определяет SVCB как RR type 64, а HTTPS как type 65. В записи есть SvcPriority, TargetName и необязательные SvcParams. Ноль означает AliasMode, ненулевое значение — ServiceMode.

AliasMode передаёт поиск конкретного сервиса другому имени. Он особенно полезен для alias на вершине зоны, где нельзя поставить обычный CNAME. Действие ограничено этим совместимым типом записи: другие RR того же имени не меняются. Параметры AliasMode игнорируются, а длина цепочки должна быть ограничена против циклов.

Имя origin также сохраняется. Следуя к TargetName провайдера, HTTPS-клиент отправляет исходное имя в SNI, проверяет сертификат для него и оставляет его в HTTP Host или :authority. Делегирован путь обнаружения, а не личность, которой доверяет пользователь.

ServiceMode связывает TargetName, порт, протоколы, адресные подсказки и расширения в единый вариант. Несколько CDN могут публиковать планы, соответствующие разным возможностям, не смешивая адрес одного с параметрами другого. Связность описания ещё не доказывает доступность или совпадение версии edge с DNS.

Сначала отбор, затем приоритет

Неверный wire-формат способен сделать недействительным весь RRset и вернуть клиента к соединению без SVCB. Конфликт известных параметров делает запись внутренне несогласованной. Обычный неизвестный ключ можно пропустить; неизвестный ключ из mandatory делает запись несовместимой.

Только оставшиеся записи сортируются по приоритету. Меньшие числа пробуются раньше, а равные случайно перемешиваются для равномерного распределения. В отличие от SRV, вес оператора отсутствует. Значение говорит «предпочесть, если совместимо», а не «исполнить без условий».

mandatory не командует сервером. Он сообщает клиенту, что игнорирование ключа разрушит смысл плана. Перечисленные ключи должны присутствовать в той же записи, а сам mandatory нельзя включать в список. Для HTTPS port и no-default-alpn автоматически обязательны при наличии: потеря порта направит к другому listener, а потеря второго признака вернёт протокол, намеренно исключённый владельцем.

DNS объявляет, handshake подтверждает

alpn перечисляет наборы протоколов на цели и позволяет сразу готовить HTTP/3 поверх QUIC или HTTP/2 поверх TLS. Реальный выбор всё равно происходит в handshake. DNS может обновиться раньше edge, UDP может блокироваться, а отдельный регион — остаться на прежнем выпуске.

Расследованию нужны два значения: ALPN из DNS и протокол, согласованный сторонами. То же относится к port: запись указывает место попытки, но политика клиента или firewall способны его запретить.

ipv4hint и ipv6hint сокращают задержку, а не заменяют A/AAAA TargetName. Если адресные ответы уже доступны, hints следует игнорировать. Иначе клиент всё равно запрашивает цель и должен использовать полученные ответы в следующих соединениях. Ранний запуск по hint может позже перейти на иной географически выбранный адрес.

Журнал обязан указать источник IP: hint, Answer, Additional, cache или разрешение proxy, вместе с TTL и сетью. Один конечный адрес не позволяет различить запланированную гонку, старый кэш, расхождение поставщиков и враждебное перенаправление.

Исходное имя проходит через все обходы

RFC 9460 допускает получение SVCB/HTTPS по недоверенному DNS. DNSSEC усиливает происхождение и целостность RRset, но не обязателен. Даже подписанный ответ не доказывает работоспособность цели, протокол сервера или корректность содержания.

Альтернативный endpoint должен подтвердить полномочия для исходного сервиса. Сертификата только для TargetName провайдера недостаточно. DNS управляет поиском, TLS — личностью peer, ALPN — соглашением конкретного соединения, HTTP — origin и ответом приложения. Успех одного слоя не свидетельствует за остальные.

HTTP существовал до SVCB, поэтому применение обычно необязательно и при обычном отсутствии возможен классический путь. Но сбой защищённого SVCB-запроса из-за аутентификации, SERVFAIL, защищённого транспорта или timeout должен остановить попытку, иначе злоумышленник сможет выборочно удалить параметры. Для незащищённого DNS локальная политика может быть иной.

В multi-CDN запросы CNAME, HTTPS и A/AAAA могут увидеть разные поколения. Клиент обязан получить адреса фактически выбранного TargetName. Приоритет работающего кода здесь означает, что общая декларация становится действенной через совместимую реализацию, а не поглощает полномочия TLS и HTTP.

Источники