SVCB и HTTPS RR меняют выбор имени и ALPN; ECH скрывает SNI, пока ClientHello не упрётся в резолвер или ротацию ECHConfigList. Здесь — матрица, пороги p95 TLS до H2 SETTINGS, откат к явному SNI, липкость GeoDNS и FAQ для JP, KR, HK, SG, US West. Серия: GeoDNS и SSH, split-horizon, QUIC.

HTTPS артефактов и SSH — разные бакеты метрик на практике; см. TCP и OpenSSH. Ниже — режимы входа, таблица порогов, шаги и тезисы для runbook.

1) SVCB без дисциплины приоритетов ломает ожидания клиентов, которые всё ещё читают только A/AAAA. 2) ECH успешен в лаборатории, но на транзитных резолверах и старых браузерных стеках даёт всплеск повторных ClientHello. 3) GeoDNS с агрессивной липкостью кэша приклеивает трафик к деградировавшему краю, пока p95 уже красный во всех смежных метро.

Режим входа Когда выбирать Риск и контрметрика
SVCB + HTTPS RR как основной путь Клиенты поддерживают HTTPS RR, нужен выбор ALPN h2 без ручных портов Расхождение SAN с TargetName; ежедневный digest расхождений
Только A/AAAA для legacy-стека Нет HTTPS RR в цепочке резолвера или запрет на TYPE65 Потеря 0-RTT и приоритетов; отдельный бакет метрик
ECH включён Требуется сокрытие SNI от пассивного наблюдения на магистрали Следить за max_age списка и корреляцией с ротацией сертификата
Откат к явному SNI Доля ошибок ECH выше порога или несовместимость Middlebox Канареечный процент трафика и отдельная гистограмма p95

Зондирование SVCB, HTTPS RR и ECH; откат к классическому SNI

На метро закрепите три профиля резолвера: публичный, split-horizon, стендовый stub. Снимайте TYPE65 и HTTPS RR с priority, target, alpn=h2; без SVCB помечайте legacy-only и не смешивайте гистограммы с ECH.

ECH: зондируйте echconfig и корреляцию с ротацией сертификата; при совместном релизе p95 часто ломается раньше 5xx. Откат к явному SNI при ошибках ECH > 0,8% за 15 мин в любом метро — канарея 5% с тегом sni_plain.

GeoDNS: TTL 120–900 с для зон failover; липкость ECS/subnet — в паспорте зоны. Сначала веса и drain на краю, потом авторитет.

Регион p95 TLS до SETTINGS (H2), мс Бюджет ошибок ECH, %
JP≤ 380≤ 0,6
KR≤ 360≤ 0,7
HK≤ 340≤ 0,8
SG≤ 320≤ 0,8
US West≤ 300≤ 0,9
p95 TLS+H2: от SYN до SETTINGS ACK по h2; без тела ответа и без SSH на бастионе.

Приёмка p95: HTTP/2 и полный цикл TLS на артефактном входе

В отчёт по SLO включайте метку времени до SETTINGS ACK по H2, иначе оптимизация застревает на первом раунде TLS, а реальные задержки мультиплексора остаются в слепой зоне. Фиксируйте версию клиентского стека, флаг encryptedClientHello и факт наличия HTTPS RR в цепочке резолвера. При регрессии сравнивайте две ревизии конфигурации края и параметры зоны DNS, не меняя оба фактора в одном изменении, чтобы сохранить причинно-следственную цепочку для постмортема.

Смотрите SETTINGS, не только первый раунд TLS: ALPN и ECH retry бьют по хвосту. При зелёной медиане режьте по ASN резолвера и доле клиентов без HTTPS RR.

Параллельно меряйте SCP/SFTP по матрице артефактов, чтобы не принять TCP за TLS. Нагрузку сравнивайте в сопоставимые окна JP и US West.

Маршрутизация по регионам: JP, KR, HK, SG, US West

JP/KR — разные строки GeoDNS; HK/SG — контроль транзита, не смешивайте p95 с JP, если CI идёт через хаб.

US West: короткий порог из-за RTT в Азию; проверьте US→SG и JP→US. PoP сверяйте с тарифами и матрицей входа.

FAQ: failover, липкость и границы ответственности DNS

TTL раньше края? Нет: сначала веса и drain, иначе ложные тревоги на авторитете.

ECH vs сертификат? Совместите unknown ech config с журналом CA; откатите список ECH до стабильного p95.

Мониторинг при явном SNI? Да — отдельная метка маршрута и SLO.

SSH? Отдельное имя и зона; см. Worker и SSH p95.

Восемь шагов приёмки перед продакшеном

  • 1. Зафиксируйте три профиля резолвера и выпишите TTL, липкость и view для каждого метро.
  • 2. Снимите SVCB и HTTPS RR, сверьте target с SAN сертификата на краю.
  • 3. Включите ECH на канареечной доле, соберите ошибки ClientHello и сравните с бюджетом таблицы.
  • 4. Измерьте p95 до SETTINGS ACK по H2 для каждого региона при типовой нагрузке CI.
  • 5. Проведите учение отката к явному SNI с автоматическим возвратом и проверкой метрик.
  • 6. Согласуйте порядок failover: край, затем веса, затем TTL, затем авторитет.
  • 7. Зафиксируйте в runbook владельцев DNS, TLS и края с контактами на окно ротации ключей.
  • 8. Архивируйте сырые трассировки p95 с метками ревизии ECHConfigList и сертификата для последующего аудита.

Формулировки для паспорта сервиса

  • SVCB — договор приоритетов DNS–TLS, не замена мониторинга края.
  • ECH без max_age и синхронизации с сертификатом бьёт p95 сильнее явного SNI.
  • Липкость GeoDNS короче окна детектора, иначе хвост TLS растёт незаметно.
Оговорка: пороги — ориентиры Halo для vpshalo; подстройте под SLO и право.

Итог. Разделяйте HTTPS и SSH, держите таблицу p95 и откат ECH→SNI. Узел — через покупку и справку.

Узел, регион и справка

Закрепите PoP под измеренный RTT и политику TLS

Токио · Сеул · Гонконг · Сингапур · Запад США — выбор узла под JP/KR/HK/SG/US West. Помощь по доступу и тарифы. Серия Halo: GeoDNS и SSH, QUIC и артефакты.

Все варианты покупки · Техноблог · Главная

Выбрать региональный узел Справка и онбординг Тарифы Другие статьи Halo