Кратко

  • RFC 6761, опубликованный в феврале 2013 года, учредил реестр IANA для доменных имён специального назначения. Новая спецификация должна ответить на семь вопросов: от действий пользователя до политики реестра и регистратора.
  • Первые записи объединили старые резервы и зоны обратного поиска частных адресов. Поведение различается: localhost требует адреса обратной петли, invalid — быстрого отрицательного ответа, а частная обратная зона может обслуживаться внутри сети.
  • RFC 8244 в 2017 году описал отсутствие формальной координации таких назначений между IETF и ICANN и неясность термина «техническое использование». Строка в реестре подтверждает назначение; работу конкретного резолвера показывает трасса запросов.

Печать в списке не отвечает на запрос

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

В 1999 году RFC 2606 зарезервировал имена для тестов, примеров, ожидаемого отказа и локального узла. Тогда вопрос состоял в том, чтобы выдуманное имя не столкнулось с действующим доменом. RFC 6761 в 2013 году перенёс внимание к выполнению: кто распознает уже зарезервированное имя, на каком этапе остановит поиск и какой ответ выдаст? Забрать имя из продажи проще, чем добиться согласованной работы разных резолверов.

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

Семь вопросов вместо одной кнопки

По RFC 6761 новое имя требует документа, принятого через Standards Action IETF либо с одобрением IESG. Документ должен назвать границы имён и отдельно объяснить их обработку семью группами. Должны ли люди замечать особый статус? Приложения? API и библиотеки разрешения? Кэширующие DNS-серверы? Авторитетные серверы? Что важно операторам? Как поступать реестрам и регистраторам с заявками?

Это не семь одинаковых команд. Для обратной зоны частных адресов, например 10.in-addr.arpa, приложение и API должны направлять обычный запрос настроенному кэширующему серверу. Сервер по умолчанию должен ответить локально, не уводя вопрос к внешним авторитетным серверам. Если в частной сети есть собственный авторитетный сервер, возможна специальная настройка. Поэтому пакет, вышедший из приложения, ещё не свидетельствует об ошибке. Решение в данном случае поручено следующему участнику цепочки.

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

Сейчас в реестре IANA перечислены, среди прочих, localhost, invalid, local, onion, home.arpa и частные обратные зоны. У каждой записи своя ссылка на источник правил. Одни имена обрабатываются в DNS особым образом, другие зависят от локального способа разрешения или контекста приложения. RFC 6761 не ограничил категорию доменами верхнего уровня и не приказал всем обходить DNS. Общая графа в таблице означает общее обозначение, а не единый механизм.

Имя уезжает, а окружение остаётся

Сотрудник копирует внутреннее имя в сообщение. Получатель открывает его в другой сети. Написание не изменилось, но настройки, придававшие имени смысл, остались на прежнем месте. Запрос может уйти не туда или никуда. RFC 8244 рассматривал подобный разрыв между именем с глобально узнаваемой формой и локальным значением. Строку легко передать; её контекст — нет.

В октябре 2017 года RFC 8244 выпустил перечень проблем, а не новый порядок работы. Между IETF и ICANN существовал канал связи, но не было формальной процедуры согласования назначений специального назначения. Не было и общепринятой границы «технического использования». Обе организации имели роль в пространстве имён, однако ни одна не могла заставить постороннего разработчика сначала получить разрешение.

В документе описаны и обычные пути к столкновению: местное имя утекает наружу; неформальное использование встречается с последующим официальным назначением; автор протокола не знает процедуры или ожидает отказа. Для оценки названного продукта потребовались бы его настройки с датами и журналы запросов. Реестр удостоверяет статус имени, а эти записи — поведение системы.

Бюрократическая ирония здесь точная: для особых имён появился аккуратный ящик, но каждая карточка в нём требовала работы семи разных отделов. Вопросы RFC 6761 заставляли расписать обязанности до внесения записи. RFC 8244 показал, что договориться о самом входе в этот ящик тоже было непросто.