Кратко

  • Записи SVCB и HTTPS связывают альтернативный узел с его параметрами и позволяют издателю рекомендовать порядок. DNSSEC способен подтвердить рекомендацию, но не совместимость клиента, достижимость, TLS-идентичность или успех приложения.
  • Исполнительная власть остаётся у клиента: он отбрасывает испорченные и несовместимые записи, понимает обязательные ключи, перемешивает равные приоритеты, применяет политику прокси и адресов, пробует, отступает и проверяет исходное имя сервиса.

Представим не аварию, а расхождение в штатной работе. Подписанный HTTPS RRset ставит HTTP/3 первым, а HTTP/2 вторым. Телефон использует первый вариант. Корпоративный ноутбук не понимает обязательный параметр и выбирает второй. Третий клиент уже начал совместимое соединение со вторым узлом и продолжает его, хотя меньший номер приоритета принадлежит другому.

Одна зона породила разные соединения без нарушения стандарта. Причина проста: зона описывает упорядоченный набор, а клиент превращает доступную часть этого набора в работающий путь.

RFC 9460 определяет SVCB как тип 64, а совместимый с ним HTTPS — как тип 65. Они доставляют сведения о соединении до первого прикладного обмена: альтернативные узлы, протоколы, порты, подсказки адресов и расширяемые параметры.

Нулевой SvcPriority означает AliasMode — делегирование сервиса к TargetName. Положительное значение означает ServiceMode, где TargetName и SvcParams одной записи образуют комплект. Связность комплекта не даёт случайно совместить порт одного CDN, ALPN другого и адрес третьего при независимой ротации RRset.

AliasMode уже CNAME по области действия. Он относится только к запрошенному SVCB-совместимому типу, не меняет остальные типы и не превращает TargetName в HTTPS-origin. Он полезен на apex, но старым клиентам по-прежнему нужны обычные A и AAAA, а глубину alias-цепи ограничивает реализация. Публикация не создаёт поддержку у неучаствующего клиента.

В ServiceMode клиент строит совместимый набор. Повреждённая кодировка может привести к отказу от всего RRset; противоречивые распознанные параметры делают запись непригодной. Неизвестный ключ обычно можно проигнорировать, кроме случая, когда он перечислен в mandatory. Тогда незнание ключа означает несовместимость, а не разрешение угадать смысл.

Это договор расширяемости. Новые необязательные функции не ломают старые реализации. Действительно необходимое свойство можно объявить обязательным и тем самым честно исключить неподготовленный клиент. Но mandatory — не рекламный рычаг: он создаёт реальную недоступность для части парка.

Реестр параметров SVCB IANA, обновлённый 25 июня 2026 года, кроме mandatory, ALPN, отмены ALPN по умолчанию, порта и подсказок IPv4/IPv6 содержит ECH, путь DoH, OHTTP, группы TLS, путь DNS over CoAP, PvD и уверенность оператора по транспортам DNS-сервера. Регистрация закрепляет номер и значение, но не всеобщую реализацию и не пригодность для любого mapping.

Приоритет тоже не команда. Меньшее положительное число — рекомендация владельца домена. Записи одного уровня клиент должен случайно перемешать для равномерной нагрузки; веса SRV здесь нет. Обычно сначала пробуют более предпочтительные совместимые варианты, затем менее предпочтительные.

RFC 9460 допускает параллельные попытки, предварительное разрешение нескольких TargetName, выбор записи без дополнительного DNS-запроса и продолжение уже начатого совместимого соединения. Поэтому по зоне нельзя однозначно предсказать первый успешный сокет.

ALPN разделяет объявление и переговоры. Параметр сообщает предлагаемые протокольные наборы; клиент оставляет поддерживаемые, а RFC 7301 регулирует выбор внутри TLS. Строка h3 в DNS не включает QUIC, не открывает UDP и не гарантирует согласие сервера.

Подсказки IP также временны. При наличии A или AAAA их следует игнорировать. Иначе клиент всё равно запрашивает TargetName и может перейти с адреса-подсказки на фактический ответ. Превращение подсказки в постоянный адресный источник мешает географической и нагрузочной политике.

Между адресами клиент может использовать Happy Eyeballs v2, соревнуя IPv6 и IPv4. Победителя определяют задержки и текущий путь, а не символ в зоне.

DNSSEC аутентифицирует публикацию. HTTPS RR не аутентичен автоматически: RFC 9460 считает DNS потенциально недоверенным каналом, а подпись и проверку — опциональными. Если клиент требует DNSSEC для A/AAAA, ту же политику следует применить к SVCB, иначе подделка обойдёт защиту адресов. Состояния проверки задаёт RFC 4035.

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

TargetName не становится идентичностью сервиса. TLS SNI и HTTP Host или :authority продолжают указывать исходный origin. RFC 9525 подтверждает: сведения SVCB/HTTPS не меняют требования PKIX для HTTP и DNS-over-TLS. CDN принимает трафик, но обязан доказать исходное имя.

Сравнение с Alt-Svc удерживает ту же границу. Alt-Svc меняет хост, порт и протокол соединения, не заменяя origin, а клиент оценивает безопасность альтернативы. HTTPS RR сообщает подобное раньше через DNS и живёт по TTL; Alt-Svc приходит через HTTP и использует ma. Семантика origin и authority из RFC 9110 остаётся выше обоих маршрутов.

Fallback поддерживает постепенное внедрение. Для существующего HTTP SVCB обычно опционален: после отказа альтернатив клиент возвращается к обычному пути. Но блокировка предпочтительного узла способна убрать ECH, HTTP/3 или иную защиту. RFC 7838 предупреждает о таком downgrade для альтернативных сервисов. Производительность и обязательный уровень безопасности требуют разных решений.

Прокси меняет и место разрешения. Именной прокси может сам получать A/AAAA, а отдельный запрос SVCB от клиента раскроет назначение ещё одной стороне. Без подходящей приватной схемы опциональный клиент должен отключить SVCB, зависимый — признать конфигурацию неверной. При использовании совместимость включает возможности и сетевое положение прокси.

RFC 9461 отображает SVCB на DoT, DoH и DoQ. Он показывает, что общий формат не отменяет протокольных правил: mapping определяет допустимые ключи, идентичность и fallback.

Разделение Heng Lu между работающим кодом, минимальной спецификацией и локализованным будущим решением и слоями реальности задаёт порядок доказательств: стандарт, публикация зоны, ответ резолвера, фильтр клиента, TLS и результат приложения проверяются отдельно.

Аудит не заканчивается типом 65. Он связывает RRset и DNSSEC с версией клиента, понятыми ключами, прокси, выбранной записью, попытками адресов, ALPN, сертификатом, причиной fallback и ответом приложения. Издатель доказывает предложение; работающий путь — использование.