Кратко

  • В строгой записи DNS полное имя заканчивается точкой корневой метки; в обычном отображении точку опускают. Эквивалентность в DNS не заставляет прикладные политики считать входы одинаковыми.
  • Проект DNSOP рекомендует хранить и показывать полные имена без точки и предостерегает от обычных строковых операций. В ходе последнего обсуждения прозвучал запрос на исполнимое правило сравнения двух форм.
  • CVE-2026-8924 даёт ограниченное свидетельство работающего кода: расхождение в curl позволило обойти проверку Public Suffix List для cookie. Границу сдвинул порядок нормализации, а не сама точка.

Точка после uk делает видимой пустую метку корня. RFC 9499 называет запись с ней строгим форматом представления, а в обычном формате разрешает её не показывать. Резолвер способен сопоставить обе строки одному месту дерева DNS. Хранилище cookie, проверка сертификата, кэш или учётная система не получают это равенство автоматически.

Этот стык оказался в текущем процессе стандартизации. 24 августа рабочая группа IETF DNSOP перевела draft-ietf-dnsop-integration-04 в Working Group Last Call, который заканчивается 7 сентября. Проект рассчитан на информационный статус. Это ещё не RFC и не свидетельство консенсуса. Документ собирает условия ответственного использования имён глобальной DNS как идентификаторов приложений.

В перечень входят жизненный цикл домена, проверка контроля, полнота, синхронизация, развитие протокола, различия панелей управления и поддержка типов записей. В разделе 3.3 рядом стоят две важные мысли. Полные имена следует обычно хранить и показывать без последней точки, кроме случаев с локальными поисковыми доменами. При этом отображение, нормализацию, сравнение, кодирование и декодирование нельзя отдавать обычным строковым функциям.

Опасность названа, но последовательность для каждого барьера ещё не стала проверяемым алгоритмом. Paul Wouters формально не возражал против публикации, однако счёл технические рекомендации недостаточно конкретными. Среди примеров он перечислил сравнение с точкой и без неё, нечувствительность DNS к регистру, A-label и U-label, отрицательное кэширование, висячие псевдонимы и сохранение исходного QNAME при обработке CNAME/DNAME. Wes Hardaker поддержал публикацию, назвав документ скорее контекстом на будущее, чем немедленным руководством.

Tim Wicinski тоже не возражал против продвижения и отметил близость последних частей раздела 3 к эксплуатации. Это индивидуальные отзывы, не решение группы.

В CVE-2026-8924 видно, почему порядок нельзя оставлять неявным. Официальное сообщение curl от 24 июня 2026 года оценивает ошибку как низкую, указывает затронутые версии с 7.46.0 по 8.20.0 и исправление в 8.21.0. Если URL-хост заканчивался точкой, например example.co.uk., сервер мог назначить cookie для co.uk.. Проверка по Public Suffix List не останавливала чрезмерно широкую область, и cookie мог позже уйти посторонним доменам.

DNS не обязан был возвращать разные адреса. Прикладная политика получила форму имени, не согласованную с формой данных о суффиксах. curl отдельно пишет, что конечная точка не передаётся в TLS SNI. Одна исходная строка могла жить по разным текстовым правилам в DNS, cookie и TLS. Более ранняя CVE-2022-30115 зафиксировала отдельное расхождение HSTS на том же представлении. Это не доказывает дефект всех реализаций, но показывает повторяемость шва.

Регистр и международные имена расширяют контракт. RFC 4343 требует безрегистрового сравнения обычных ASCII-меток DNS, но предупреждает: вне DNS имя может стать регистрозависимым индексом базы или входом аутентификации. RFC 5890 различает Unicode U-label и совместимую с ASCII A-label, оставляя соглашение о последней точке вне своей области. Универсальной функции «перевести в нижний регистр и отрезать знак» поэтому не существует.

Проверяемая интеграция сохраняет цепочку квитанций. Нужны исходный ввод, явность корня и разрешение локального поиска; разобранные метки и абсолютное либо относительное состояние; каноническая форма для конкретного решения; версия Public Suffix List, профиля IDNA или правила сертификата; само решение и наблюдаемый эффект — сохранённый ключ, отправленные данные или отказ.

Разделение ограничивает смысл каждого результата. Равенство имён в DNS не подтверждает контроль регистранта. Проверка домена не удостоверяет все службы. Сертификат не разрешает все действия. Совпадение cookie-домена не доказывает конечного получателя или результата.

Таким образом, Last Call оставляет вопрос не о нужности точки, а о полномочии определить каноническую форму и момент её применения. Если приложение сначала решило вопрос суффикса, origin или доступа, а затем выровняло запись в журнале, граница уже сдвинулась. Единообразным стал отчёт, не исходное решение.

Источники