Кратко

  • RFC 8552, опубликованный в марте 2019 года, описал поддомен с подчёркиванием как место для записей, относящихся к родительскому домену. Глобальным считается подчёркнутое имя, ближайшее к корню DNS.
  • Реестр IANA закрепляет сочетание типа ресурсной записи и глобального имени. Экспертная проверка защищает эту пару от повторного назначения; нижние уровни ветки определяет соответствующий протокол.
  • RFC 8553 связал прежние спецификации с единым реестром, не меняя работающие программы и эксплуатационные правила. Запись в реестре доказывает распределение имени, а содержимое конкретной зоны показывает авторитетный DNS-ответ.

Универсальный тип требовал точного адреса

Основа DNS довольно сдержанна. Она задаёт имена и типы записей, но не приписывает каждому фрагменту доменного имени универсальный смысл и не запрещает размещать тип записи в определённой части дерева. Благодаря этому приложения могли использовать существующий тип вместо ожидания нового номера для каждого набора инструкций. Цена свободы проявилась там, где разные инструкции оказывались рядом.

Представим TXT. Два протокола могут публиковать TXT для одного домена, однако читать в них совершенно разные вещи. Если оба набора лежат непосредственно у имени домена, клиенту приходится разбираться уже после получения ответа. RFC 8552 предлагает задать область действия в самом имени: данные размещаются под веткой вроде _name.example.org, а example.org остаётся доменом, которого эти данные касаются. Клиент спрашивает нужную ветку и получает её записи.

Начальное подчёркивание отделяет такую метку от обычных имён хостов. Это полезный знак на двери, а не новая форма пакета DNS. Тип записи остаётся прежним; адрес указывает, по какому протоколу следует трактовать ответ. Внутри одной спецификации соглашение выглядит безобидно. Между независимыми спецификациями оно требует ответа на вопрос, кто вправе занять общий адрес.

Приём появился раньше реестра. RFC 2782 в феврале 2000 года использовал форму _Service._Proto.Name для SRV и ставил подчёркивания перед службой и протоколом, чтобы избежать совпадений с обычными именами хостов. DNS-Based Service Discovery позднее применил уже известное соглашение. Эти документы описывают собственные запросы и поведение клиентов. Задача RFC 8552 была шире: согласовать внешние имена веток, которые могли независимо предложить разные авторы.

Общая дверь находится ближе к корню

В имени бывает несколько подчёркнутых меток. Глобальной RFC 8552 считает ту, что ближе всего к корню DNS. Все метки ниже неё находятся внутри области, описанной протоколом глобальной метки. При чтении имени слева направо легко ошибиться и принять за главную первую встреченную метку. Для распределения имён важна именно позиция в дереве, а не порядок букв на экране.

IANA ведёт реестр глобальных имён узлов DNS с подчёркиванием. В таблице стоят тип записи, имя узла и ссылка на документ. Ключом служит пара (RR Type, _NODE NAME). Один тип может использоваться под разными глобальными метками; одна метка может встречаться при разных типах. Опасно повторное назначение обеих частей сразу. В таком случае два протокола могли бы ожидать от одной и той же точки дерева разные ответы.

Процедура регистрации называется Expert Review. RFC 8552 поручает эксперту проверить ясность и уникальность пары, оставляя общую оценку качества протокола за пределами этой процедуры. Утверждённая запись не свидетельствует, что приложение хорошо спроектировано. Она также не подтверждает, что администратор домена наполнил ветку данными, а программа задала правильный запрос. Реестр решает конфликт назначений, а не все проблемы работающей системы.

Отсюда три разных документа для трёх разных вопросов. Реестр сообщает, кому закреплено сочетание имени и типа. Указанная спецификация объясняет внутренние метки и формат применения. Авторитетная зона конкретного домена показывает опубликованные записи. Подмена третьего первым создаёт красивую, но пустую картину развёртывания.

Старые документы догнали действующую практику

К моменту появления реестра имена с подчёркиванием жили уже много лет. Прежние RFC создавали их без единого списка, которого тогда не было. Вышедший вместе с RFC 8552 RFC 8553 обновил ссылки в старых спецификациях и привёл шаблоны для SRV и URI к общему порядку регистрации глобальных имён.

Поправка была сделана в бумагах, а не в ночной замене записей всей сети. RFC 8553 прямо сохраняет существующее программное обеспечение и эксплуатационную практику. Публикация реестра не меняла формат DNS на проводе. Она уточняла, как новый автор получает имя и как читатель старого RFC находит актуальный источник распределения.

В этой истории виден предел местного порядка. Один автор может аккуратно определить ветку в своём протоколе. Второй сделает то же самое. Если оба используют одну глобальную метку и один тип, их аккуратность не спасает общего клиента от столкновения смыслов. Централизовать всё дерево DNS не требовалось. Достаточно было согласовать самый верхний общий участок ветки.

Официальные тексты подтверждают правило, ключ реестра и изменения прежних документов. Для утверждения, что определённая служба действительно работает через такую ветку, нужны датированный снимок её авторитетной зоны и запрос её клиента. Распределение адреса и его использование остаются двумя отдельными фактами.