Authenticated service endpoint

DNS отвечает «куда попробовать подключиться», а защищённое приложение должно отдельно доказать, что соединение установлено именно с нужной службой.

1. 01

   После разрешения имени клиент строит ожидаемый идентификатор из доверенных исходных данных и сопоставляет его с именем в сертификате фактической стороны TLS.

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

2. 02

   Запись A/AAAA, SRV, SVCB или HTTPS выбирает возможную конечную точку, но не выдаёт приложению права и не заменяет проверку текущей работоспособности.

   Граница применимости: Данные поиска DNS и проверенный сеанс приложения с нужными правами.

1. Сохраните исходное проверяемое имя.
2. Найдите возможную конечную точку.
3. Проверьте сертификат и действие.

• Первичная спецификация

  Service Identity in TLS

  Internet Engineering Task Force · RFC 9525, November 2023

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

  Открыть первоисточник ↗
• Первичная спецификация

  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.

  Открыть первоисточник ↗
• Первичная спецификация

  Service Binding and Parameter Specification via the DNS

  Internet Engineering Task Force · RFC 9460, November 2023

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

  Открыть первоисточник ↗
• Первичная спецификация

  DNS Security Introduction and Requirements

  Internet Engineering Task Force · RFC 4033, March 2005

  Определяет DNSSEC goals, resolver security states, trust anchors и границы защиты.

  Открыть первоисточник ↗