Кратко

  • Текущий draft рабочей группы DNSOP описывает NS RRSet из одной записи с пустой целью: он отмечает границу дочерней зоны, не публикуя пригодные для публичного доступа авторитетные серверы.
  • Сигнал не даёт трактовать аутентифицированное отрицание из глобального DNS как универсальное несуществование, когда устройство затем попадает в частное пространство имён.
  • Публикация родителя, увиденный referral, частный путь, полномочия дочерней зоны, проверка DNSSEC и результат приложения требуют отдельных подтверждений.

Делегация скрывала два разных обещания

Обычная делегация одновременно сообщает, что здесь начинается дочерняя зона, и перечисляет серверы, через которые она доступна. В split DNS первое утверждение может быть истинным, а второе — нет. example.com публикуется глобально, но corp.example.com обслуживают только внутренние resolver. Указывать вымышленный публичный сервер было бы не конфигурацией, а ложью.

Revision 00 предлагает строгое представление: единственная NS-запись с пустым NSDNAME, то есть NS с точкой в качестве цели. Родитель признаёт границу, но сообщает, что его namespace не предоставляет авторитетный сервер для продолжения. Если RRSet содержит и обычные цели, и пустую, draft не придаёт ему такого смысла.

Подход уже знаком DNS. Null MX говорит, что домен не принимает почту. Точка в SRV означает, что сервис недоступен. Пустая цель AliasMode SVCB несёт сходный смысл. Эти примеры не доказывают совместимость нового NS-механизма, но показывают: явное отсутствие функции точнее фиктивного адреса.

Отрицательный ответ переживает смену сети

За пределами офиса ноутбук может спросить глобальный DNS о внутреннем имени. Валидирующий resolver получает подписанное отрицание и сохраняет его. Затем устройство входит в корпоративную сеть, где внутренняя authority даёт положительный ответ. Если старое отрицание считать фактом для всех пространств имён, корректный частный ответ покажется bogus.

Zone cut to nowhere сужает публичное утверждение. Родитель не отрицает любую нижележащую зону, а возвращает referral, чьи серверы нельзя разрешить или достичь. Специальная обработка не требуется: resolver ведёт себя как при делегации к недостижимым серверам. Из публичной сети ребёнок по-прежнему недоступен.

Различается основание отказа. NXDOMAIN и частная граница могут одинаково выглядеть для приложения снаружи. После перехода в другую сеть они создают разные обязанности для cache и validation.

Одна строка не заменяет шесть квитанций

Первая квитанция — точная конфигурация родителя. Вторая — DNSSEC-аутентификация опубликованного родителем RRSet. Ни одна не называет частный сервер.

Третья — фактически полученный resolver referral с конкретными TTL и статусом проверки. Устаревший cache или посредник могут отделить wire response от zone file.

Четвёртая — выбор частного пути после смены сети. Устройство должно получить внутренний resolver или forwarding rule, способные найти дочернюю зону. Пустая публичная цель не обнаруживает путь и не разрешает доступ.

Пятая — ответ дочерней authority и его DNSSEC-результат. Шестая — использование ответа приложением и исход сервиса. Успешный lookup не доказывает работу сервиса, а запись родителя не доказывает даже успешный lookup.

DS связывает ключ, а не сеть

Если администратор родителя знает ключи подписи дочерней зоны, draft позволяет опубликовать DS вместе с пустым NS. Позднее resolver, обнаружив подписанную частную зону, сможет продолжить цепочку доверия.

Предпосылка жёсткая. Если разные private views используют разные ключи или часть из них не подписана, один публичный DS не представляет их все. Revision 00 рекомендует не использовать secure delegation в такой ситуации. Выбор DS фиксирует криптографическую identity, а не просто «усиливает безопасность».

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

Статус draft ограничивает выводы

Revision 00 от 23 сентября 2026 года — активный Standards Track Internet-Draft рабочей группы DNSOP. Это не RFC и не окончательный консенсус IETF. Пример INTERNAL в root носит пояснительный характер и не даёт IANA эксплуатационных указаний.

Авторы описывают эксперименты, не обнаружившие признаков широких проблем, но отмечают риск несовместимых предположений в ПО и вредной нагрузки на root servers. Это основание для измерений, а не универсальный сертификат совместимости.

Практическое исключение связано с ACME DNS-01. Организация, временно публикующая публичные TXT под частной ветвью, не может без изменений утверждать, что там нет полезного публичного DNS-пути. Минимальный сигнал действителен только при согласованной архитектуре.

Источники