DNS HTTPS/SVCB: как ALPN и ECH ускоряют и прячут ваш трафик

DNS долгое время не вмешивался в детали HTTP и TLS: максимум A/AAAA, иногда SRV, а всё остальное делали редиректы, HSTS и Alt-Svc. С появлением записей SVCB и HTTPS ситуация изменилась: теперь клиент может ещё на этапе резолвинга узнать, какие протоколы доступны (через ALPN), на какой порт идти, какие адреса предпочесть, а при необходимости получить параметры для ECH и спрятать SNI. В итоге сокращаются круги рукопожатий, а приватность заметно повышается.

Что такое SVCB и HTTPS-записи и чем они отличаются от A/AAAA/CNAME

SVCB (Service Binding) — это общий механизм публикации «метаданных подключения» для сервиса. HTTPS-запись — это специализированный вариант SVCB для веба. В обеих используется единая модель: приоритет (SvcPriority), целевое имя (TargetName) и набор параметров (SvcParams). Возможны два режима:

• AliasForm: SvcPriority = 0, запись указывает на другое имя. Это похоже на CNAME, но работает и на апексе (корне домена), где CNAME запрещён. Применимо для «алиаса на CDN».
• ServiceForm: SvcPriority > 0, мы публикуем конкретные параметры подключения: alpn, port, ipv4hint, ipv6hint, ech и т.д. TargetName может быть . (то же имя, что и у владельца записи), либо сторонним именем.

Клиент получает одну или несколько HTTPS/SVCB-записей и выбирает подходящую: обычно самую приоритетную (минимальный SvcPriority), у которой пересекаются поддерживаемые ALPN. Если клиент или резолвер не понимают SVCB/HTTPS, всё продолжит работать по старинке — через A/AAAA, возможно с Alt-Svc внутри HTTP.

ALPN: объявляем протоколы заранее (HTTP/2, HTTP/3)

ALPN (Application-Layer Protocol Negotiation) указывает, какие протоколы сервер готов принять на целевом адресе и порту. В HTTPS/SVCB это список токенов: h3 для HTTP/3 (QUIC), h2 для HTTP/2 и при необходимости http/1.1. Есть флаг no-default-alpn, который запрещает клиенту «додумывать» протоколы по умолчанию.

Почему это важно? Клиент может принять решение ещё до TCP/QUIC SYN: выбрать стек соединения, сразу пойти в HTTP/3 или, при отсутствии поддержки, в HTTP/2. Это сокращает пробы и ускоряет первый байт.

Пример публикации «чистого сервиса» на порту 443 с HTTP/3 и HTTP/2, без алиаса:

example.com. 300 IN HTTPS 1 . alpn=h3,h2 port=443 ipv4hint=203.0.113.10,203.0.113.11

Если вы объявите h3, но сервер не умеет HTTP/3 (QUIC), часть клиентов сделает дауншифт, но другие могут заметно задержаться на ретраях. Поэтому сначала включаем серверный HTTP/3, затем публикуем h3 в DNS — не наоборот.

ECH: шифруем ClientHello и скрываем SNI

Encrypted ClientHello двигает приватность TLS дальше: до ECH имя сайта (SNI) было видно на проводе, что давало ценную метку для цензуры и трекинга. С ECH SNI шифруется под «публичный» ключ из DNS. Браузер достаёт параметр ech из HTTPS/SVCB, выбирает подходящую конфигурацию и шифрует ClientHello, отправляя на внешний public_name (часто это фронтовое имя CDN).

Несколько важных практических моментов:

• Где брать ech? Сейчас это чаще всего домен «за CDN», где провайдер генерирует и ротирует ключи сам. Самостоятельное внедрение требует TLS-терминатора с поддержкой ECH (часто стек на базе BoringSSL), что в классических конфигурациях OpenSSL пока редкость. Если вы ведёте фронт на собственном сервере или на VDS, проверяйте поддержку в выбранном софте.
• Совместимость клиентов. Крупные браузеры включают ECH преимущественно при «защищённом DNS» (DoH/DoT) и достаточном сигнале доверия к резолверу. Без этого клиент может игнорировать ech, даже если записи в зоне верны.
• Паблик-имя (outer SNI). Оно должно вести на корректный фронт и иметь действующий сертификат. При фолбэке без ECH пользователь иначе увидит ошибку TLS. Проверьте актуальность цепочки и срок действия через свои SSL-сертификаты.
• Ротация и TTL. Меняйте ech с запасом по TTL, поддерживайте перекрытие старых и новых ключей, чтобы клиенты с кэшем не ломались.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

AliasForm для апекса и CDN

Одна из самых практичных фич — возможность «алиасить» апекс домена на CDN, не нарушая требований DNS (где CNAME на апексе запрещён). Пример:

example.com. 300 IN HTTPS 0 cdn.example.net.

Клиент, поняв HTTPS-запись, резолвит cdn.example.net. и следует его политике (адреса, ALPN, ECH). Старые клиенты просто используют A/AAAA, которые вы оставляете на апексе для обратной совместимости. Подробно о том, как решать задачу «алиаса апекса на CDN», см. разбор про ANAME/ALIAS: алиас апекса на CDN.

Ключевые параметры HTTPS/SVCB

• alpn=... — список поддерживаемых протоколов. Типичные значения: h3, h2, http/1.1.
• port=... — нестандартный порт сервиса (по умолчанию 443 для HTTPS). Используйте осторожно: тактика «HTTPS на 444» редко нужна.
• ipv4hint=..., ipv6hint=... — подсказки адресов; клиент может попытаться подключаться к ним в первую очередь. Это не жёсткая привязка, а оптимизация.
• ech=... — base64-параметр с конфигурацией ECH. Источник — ваш CDN или TLS-терминатор с поддержкой ECH.
• no-default-alpn — флаг, запрещающий использовать протоколы «по умолчанию». Полезно для строгих конфигураций.

Поддержка: резолверы, браузеры, сервера

HTTPS/SVCB давно присутствуют в современных резолверах и браузерах. Важно: ECH в браузерах обычно активируется только при использовании защищённого DNS (DoH/DoT) — это снижает риск атак подмены при доставке конфигурации ECH. DNSSEC может усилить доверие, но не является строгим требованием клиента.

На стороне серверов картина менее равномерная: HTTP/3 зрел и доступен в популярных веб-серверах и балансировщиках. А вот ECH в мейнстрим-стаках на базе OpenSSL пока скорее исключение. Если вы терминируете HTTP/3 на edge-прокси (например, HAProxy с QUIC), смотрите наши практики по терминации: терминация HTTP/3/QUIC в HAProxy.

План внедрения: от безопасного минимума к ECH

Шаг 1. Подготовка и инвентаризация

• Проверьте, что ваш DNS-провайдер умеет типы HTTPS/SVCB и нужные параметры. Если нет — возможен бридж через API или смена провайдера.
• Убедитесь, что фронты реально поддерживают HTTP/2, а при необходимости HTTP/3, прежде чем объявлять alpn в DNS.
• Согласуйте TTL: на старте возьмите 300–900 секунд, чтобы иметь быстрый откат.

Шаг 2. Публикуем HTTPS без алиаса (ServiceForm)

Пример, когда вы обслуживаете трафик сами, на 443, с HTTP/2 и HTTP/3:

example.com. 600 IN HTTPS 1 . alpn=h3,h2 port=443
www.example.com. 600 IN HTTPS 1 . alpn=h3,h2 port=443 ipv4hint=203.0.113.10

Проверка:

dig +multi example.com HTTPS

Если ответы приходят корректно, оставьте запись на низком TTL и проконтролируйте метрики: долю HTTP/3, время установления соединения, рост ошибок рукопожатия.

Шаг 3. Альтернативно: AliasForm для апекса на CDN

Для апекса на CDN:

example.com. 300 IN HTTPS 0 cdn.example.net.

Не убирайте A/AAAA на старте — оставьте совместимость и возможность отката. Когда убедитесь, что доля клиентов с поддержкой HTTPS-записи достаточна и поведение стабильное, сможете упростить конфигурацию.

Шаг 4. Активируем ECH

Если CDN выдаёт параметр ech для вашего домена, добавьте его в ServiceForm (если самостоятельно объявляете параметры) либо он придёт транзитивно через AliasForm. Для самохостинга используйте терминатор с поддержкой ECH и автоматизируйте ротацию ключей. Удобнее это делать на управляемом фронте, например на своём VDS.

Проверка ECH — тонкая: большинство инструментов покажет лишь факт наличия ech в записи. Убедиться в шифровании SNI можно через анализ трафика на границе (отсутствие явного SNI в ClientHello) или встроенной диагностикой браузера/библиотеки.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Диагностика и тестирование

• Смотреть записи. Используйте dig example.com HTTPS и при необходимости dig _sni.example.com SVCB. Проверяйте alpn, port, ipv4hint, ech.
• Проверить HTTP/3. Современный curl умеет --http3. Для полноты сравните с --http2 и оцените тайминги.
• Сниффинг рукопожатия. В ClientHello без ECH SNI виден явно. С ECH он отсутствует или зашифрован, а виден лишь outer SNI (public_name).
• Браузерные флаги. Включение/выключение «защищённого DNS» меняет поведение ECH и помогает валидировать реальную ветку кода клиента.

# Посмотреть HTTPS-запись
dig +multi example.com HTTPS
# С адресными подсказками и ECH (пример ответа)
;example.com. IN HTTPS
example.com. 600 IN HTTPS 1 . alpn="h3","h2" port=443 ipv4hint=203.0.113.10,203.0.113.11 ech=AEcCAX... (base64)
# Проверка HTTP/3 доступности
curl --http3 -I https://example.com
curl --http2 -I https://example.com

Производительность и отказоустойчивость

HTTPS/SVCB экономит раунды: клиент сразу знает, куда и как соединяться. Это особенно заметно в мобильных сетях или при холодных кэшах DNS. Параметры ipv4hint/ipv6hint помогают уменьшить издержки на пробу адресов (Happy Eyeballs), а приоритеты записей позволяют строить многоступенчатые схемы фолбэка: от премиального фронта к резервному.

При этом помните, что это подсказки, а не директивы. Клиент может игнорировать подсказанные адреса, если его политика считает иначе (например, на основании прошлых ошибок). Для управляемой маршрутизации по регионам используйте GeoDNS на уровне авторитативных серверов, публикуя разные наборы HTTPS/SVCB для разных континентов.

Безопасность и типичные ошибки

• Объявили h3, но не включили QUIC. Клиенты будут ретраить и дауншифтиться, рост TTFB неминуем. Правильный порядок — сначала включить серверный HTTP/3, потом обновить DNS.
• Неверный port. Если публикуете нестандартный порт, убедитесь в симметрии с реальной конфигурацией балансировщика и правилами межсетевого экрана.
• Сломанный ech. Неподходящий формат или устаревшая конфигурация приведут к фолбэку без ECH, в худшем случае — к ошибкам рукопожатия. Держите окна перекрытия при ротации ключей.
• Несогласованность с Alt-Svc. Вы объявляете в DNS одно, а Alt-Svc в HTTP — другое. Оптимально синхронизировать объявления: HTTPS/SVCB — источник правды, Alt-Svc — как бэкап.
• Публичное имя ECH ведёт не туда. При фолбэке пользователь увидит ошибку TLS. Проверьте сертификаты и маршрутизацию для outer SNI.

FAQ

Нужно ли включать DNSSEC для ECH? Строго нет, но это повышает доверие к данным зоны. Большинство клиентов связывает ECH с «защищённым DNS» (DoH/DoT); DNSSEC — дополнительный плюс, но не условие.

Заменяет ли HTTPS/SVCB Alt-Svc? В долгосрочной перспективе — да. На практике имеет смысл оставить Alt-Svc как страховку на период миграции.

Можно ли с помощью SVCB/HTTPS выразить приоритеты и весовые схемы как в SRV? В SVCB используется приоритет (меньше — лучше). Весов как в SRV нет; многовариантный выбор делайте через разные приоритеты плюс политику клиента и GeoDNS.

Повлияет ли это на почту и другие протоколы? Нет, HTTPS/SVCB касается веб-трафика. Для SMTP/IMAP есть свои механики (MX, TLSA, SRV).

Нужно ли срочно включать ECH? Полезно с точки зрения приватности. Если поддержка есть у вашего CDN — включайте. Для самохостинга сначала оцените готовность стека и процесс ротации ключей.

Чек-лист внедрения

• Сверьте поддержку HTTPS/SVCB у DNS-провайдера и резолверов вашей аудитории.
• Включите HTTP/3 на фронтах, затем добавьте alpn=h3,h2 в DNS.
• Для апекса на CDN используйте AliasForm с SvcPriority=0.
• Тестируйте с коротким TTL (300–900), соберите метрики, затем повышайте TTL.
• Если доступен ECH, включайте с автоматической ротацией и перекрытием ключей.
• Синхронизируйте Alt-Svc и HTTPS/SVCB, избегайте противоречий.

Итоги

HTTPS/SVCB — это новая точка управления вебом на уровне DNS: ускорение за счёт раннего выбора протокола и адреса, упрощение миграций (особенно с CDN и апексом) и повышение приватности через ECH. Внедряйте поэтапно: сначала HTTP/3 и ALPN, затем AliasForm (если нужен апекс-алиас), после чего подключайте ECH. Такой маршрут безопасен, легко откатывается и уже сегодня даёт заметную пользу пользователю.