DNS и разрешение имён

Запись HTTPS в DNS

Определение

Запись HTTPS в DNS — тип ресурсной записи, который по модели SVCB описывает подключение к службе HTTP: имя цели, протоколы ALPN, порт и подсказки адресов. Полученная запись — ещё не сеанс: подлинность конечной точки клиент проверяет по обычным правилам PKIX.

Также ищут: HTTPS RR · DNS HTTPS record · HTTPS resource record

Зачем это знать

Запись может помочь выбрать подходящий протокол и конечную точку раньше, но её успешное получение ещё не является успешным HTTPS-сеансом. Нужны совместимый клиент и проверка исходной службы.

Связи из словаря

Карта понятия

Доказательная часть

Что подтверждено

  1. Запись HTTPS применяет модель SVCB к исходным адресам HTTP и может публиковать TargetName, ALPN, порт и подсказки адресов.

    Граница применимости: Применение записи HTTPS по RFC 9460.

  2. Использование записи HTTPS не меняет обычные требования PKIX к подлинности выбранной конечной точки соединения.

    Граница применимости: Поиск через запись HTTPS с последующей проверкой службы по TLS.

  3. Параметр alpn может объявлять протоколы, например h2 или h3. Объявление возможности в DNS не подтверждает, что клиент установил соответствующее соединение и проверил сервер.

    Граница применимости: Параметры HTTPS и SVCB по RFC 9460; результаты TLS или QUIC устанавливаются при фактическом подключении.

  4. Режим псевдонима записи HTTPS можно применять на вершине зоны без превращения самого имени в обычный CNAME. Поэтому правило несовместимости CNAME с SOA и NS нельзя механически переносить на тип HTTPS.

    Граница применимости: Сопоставление ограничения CNAME и замысла AliasMode в RFC 9460; поддержка и настройка конкретного DNS-оператора проверяются отдельно.

  5. В ServiceMode записи HTTPS имя цели «.» обозначает имя владельца записи. В SRV цель «.» сообщает о недоступности службы; одинаковый символ имеет разные значения в этих двух форматах.

    Граница применимости: Сравнение положительного SvcPriority у HTTPS по RFC 9460 с полем цели SRV по RFC 2782; другие режимы HTTPS сюда не входят.

  6. Запрос A или AAAA не проверяет, как приложение использует HTTPS-запись. Для её приёмки нужен клиент, понимающий этот профиль, и наблюдение выбранного им способа соединения.

    Граница применимости: Редакторское правило проверки из разных типов DNS и профиля HTTPS; не заявляет поддержку записи конкретной версией браузера.

  7. Выбор конечной точки через HTTPS-запись не является перенаправлением HTTP на другой ресурс. Исходная служба и её идентификация сохраняют свой смысл; переход по новому URL задаёт отдельный ответ приложения.

    Граница применимости: Сопоставление привязки службы RFC 9460 и перенаправлений RFC 9110; DNS не задаёт код перенаправления HTTP.

Граница терминов

Не путать

Запись HTTPS в DNS Привязка службы — запись SVCB

HTTPS использует модель SVCB с правилами профиля HTTP. Общий синтаксис не отменяет проверки режима, совместимых параметров и ожидаемой идентичности службы.

Запись HTTPS в DNS Псевдоним DNS — запись CNAME

CNAME меняет разрешение имени по классическому алгоритму DNS. HTTPS описывает привязку службы, включая собственный режим псевдонима; это разные типы и разные ограничения.

Перед спецификацией

Что проверить

  1. Запросите тип HTTPS для имени, предусмотренного профилем нужной службы.
  2. Разберите режим, приоритет и значение имени цели вместе.
  3. Проверьте обязательные параметры, ALPN и совместимость клиента.
  4. Отдельно обработайте подсказки адресов и адресные наборы цели.
  5. Наблюдайте фактически установленное соединение, включая отказ выбранного варианта.
  6. Проверьте сертификат и право представлять исходную службу.
  7. Полезный ответ HTTP и возможное перенаправление проверяйте на уровне приложения.
Открытые основания

Первоисточники

  • Стандарт6
  • Первичная спецификация
    Service Binding and Parameter Specification via the DNS Internet Engineering Task Force · RFC 9460, November 2023 · проверено

    Определяет SVCB и HTTPS records, alternative endpoints и extensible service parameters.

    Утверждения: 01 · 02 · 03 · 04 · 05 · 06 · 07

  • Первичная спецификация
    Service Identity in TLS Internet Engineering Task Force · RFC 9525, November 2023 · проверено

    Задаёт construction и verification reference identifiers для TLS services; server identity находится в subjectAltName, не в commonName.

    Утверждения: 02

  • Первичная спецификация
    Clarifications to the DNS Specification Internet Engineering Task Force · RFC 2181, July 1997 · проверено

    Уточняет RRset, TTL, authoritative ranking и canonical-name semantics.

    Утверждения: 04

  • Первичная спецификация
    A DNS RR for Specifying the Location of Services Internet Engineering Task Force · RFC 2782, February 2000 · проверено

    Определяет SRV target, port, priority и relative weight для service location.

    Утверждения: 05

  • Первичная спецификация
    Domain Names — Implementation and Specification Internet Engineering Task Force · RFC 1035, November 1987 · проверено

    Задаёт DNS wire format, master files и базовые resource records A, CNAME, MX, NS и SOA.

    Утверждения: 06

  • Первичная спецификация
    HTTP Semantics Internet Engineering Task Force · RFC 9110, June 2022 · проверено

    Определяет stateless HTTP, origin server, intermediaries, target URI и security significance полей authority и Host.

    Утверждения: 07

Карта знаний

Связанные понятия

Из знания — в навык

Курсы по теме

Подтвердите действие