Кратко

  • В RFC 9704 локальное заявление о зоне ответственности резолвера проверяется по публичной записи. В самой записи не требуется открыто перечислять частные поддомены.
  • Имя, используемое для аутентификации резолвера, остаётся публичным. Защита списка имён не равнозначна отсутствию любых раскрытий, а право разрешать имя не даёт доступа к приложению.
  • Согласие на стабильное внутреннее поддерево может сократить число публичных изменений. Одновременно оно оставляет больше пространства для последующего добавления имён без нового согласования каждого из них.

У согласия на внутренний DNS может быть два разных срока жизни. Один относится к тому, что организация решила разрешить. Другой — к сведениям, которыми в конкретный момент располагает клиент. При обновлении эти сроки не обязаны совпадать: часть устройств ещё использует действующее старое заявление, пока другие уже получили новое. Поэтому вопрос «опубликована ли новая запись?» оказывается недостаточным даже тогда, когда сама запись совершенно корректна.

Из этой эксплуатационной детали видно устройство RFC 9704, опубликованного в январе 2025 года в рамках процесса стандартизации IETF. Локальная сеть сообщает клиенту, за какие частные имена предлагает отвечать её резолвер. Публичная родительская зона отдельно подтверждает согласие. Разнесение сведений позволяет не превращать подтверждение в открытый каталог внутренних имён. Оно же требует согласованного изменения двух наборов информации.

Это анализ предложенного стандарта, а не отчёт о его массовом внедрении. Рассмотренные документы не позволяют оценить распространённость поддержки, измерить экономию или утверждать, что определённая организация уже решила с его помощью проблему утечки.

Что именно подтверждает родительская зона

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

RFC 9704 рассматривает гибридного клиента: для определённых имён, укоренённых в глобальном DNS, он использует локальный резолвер, а для остальных сохраняет другой способ разрешения. Клиенты, которые всегда разрешают имена только локально либо всегда используют внешний или полностью самостоятельный путь, находятся за пределами этого сценария. Имена специального назначения, включая local. и home.arpa., нельзя проверять таким способом.

Необходимо содействие публичного родительского домена. Поэтому протокол не выдаёт оператору сети право фильтровать произвольные чужие домены. Локальный резолвер также должен поддерживать аутентифицированное шифрованное соединение. Это ограниченное подтверждение полномочий для конкретных имён, а не общая презумпция доверия ко всему, что сообщает ближайшая сеть.

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

В публичной зоне размещается проверочная TXT-запись. Её имя объединяет имя резолвера, _splitdns-challenge и родительский домен. Значение формируется по строго определённому представлению заявления: имена канонизируются и сортируются, родительский суффикс заменяется согласно формату, в вычисление входят длина соли и сама соль. Полученный хеш представлен в установленной кодировке base64url.

Такая точность нужна не ради формальности. Клиент проверяет конкретный набор данных, а не приблизительное совпадение намерений двух администраторов. Но публичной стороне не нужно перечислять весь набор частных поддоменов открытым текстом: клиент уже получил сведения локально и может сопоставить их с проверочным значением.

Отсутствие списка не означает отсутствие наблюдателей

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

Особое значение имеет то, что всё-таки публикуется. Имя аутентификации резолвера присутствует в имени проверочной записи. RFC 9704 прямо предупреждает о возможном раскрытии через этот элемент и рекомендует выбирать имя без чувствительного содержания.

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

Здесь полезно различать адресуемость, аутентификацию и полномочия. RFC 9463 описывает передачу имени аутентификации резолвера вместе с адресами и параметрами сервиса. Соответствие сертификата этому имени подтверждает соединение с указанной идентичностью. Оно не доказывает безопасность канала, через который клиенту предложили эту конфигурацию, и не устанавливает само по себе доверие к сети. Злоумышленник может иметь действительный сертификат для собственного резолвера.

Шифрование также не уменьшает объём сведений, доступных самому резолверу из направленных ему запросов. Поэтому выражение «используем защищённый DNS» не отвечает сразу на все вопросы: кому разрешено отвечать за имя, кто видит запрос и какую информацию несёт публичное имя отвечающей стороны. Согласие родительской зоны решает первую задачу в установленном протоколом объёме, но не подменяет остальные.

Проверка не должна зависеть от автора заявления

Публичное подтверждение должно проверяться способом, результат которого локальный оператор не может изменить. Иначе оператор смог бы сообщить о собственных полномочиях, а затем подать клиенту подходящее «независимое» подтверждение. Разделение данных по двум адресам не имело бы смысла, если обе версии оставались бы под одной бесконтрольной интерпретацией.

Один путь — ранее настроенный внешний зашифрованный резолвер. При этом сохраняются обычные правила принятия его ответов; отсутствие ответа в разумный срок означает неуспешную проверку. Другой путь — полная локальная проверка DNSSEC. Результат Secure пригоден для использования; Bogus и Indeterminate не принимаются. При Insecure следует попробовать иной способ, а при отсутствии такой возможности проверка завершается неудачей.

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

Полномочие относится к конкретному имени аутентификации резолвера. Успех одной проверки не распространяет его на все резолверы в той же сети. И даже корректно подтверждённое разрешение имени не открывает приложение пользователю. Доступ к сервису по-прежнему требует собственных механизмов идентификации и контроля.

Руководство ASD's ACSC по технологиям шлюзов подчёркивает смежную границу: разделение ответов DNS по IP-адресу не следует считать механизмом безопасности. Перед предоставлением внутреннего представления внешним поставщикам услуг нужно рассмотреть модель доверия и угроз. Это рекомендации по проектированию, а не доказательство внедрения RFC 9704 или универсальное юридическое требование.

Удобная граница становится границей полномочий

RFC 9704 отмечает возможность объединения имён под дочерней зоной: это способ реже менять проверочную запись. При достаточно стабильной границе появление ещё одного имени внутри неё может не требовать нового публичного изменения. Но объединение не является условием сокрытия списка имён. Нельзя выдавать выбор более широкого согласия за неизбежную плату за конфиденциальность.

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

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

Пока выполняется переход, контекст нужен и клиентам. Новую проверочную запись следует опубликовать до изменения соответствующего локального заявления. Старую необходимо сохранять до истечения связанной аренды DHCP или информации домена конфигурации. При изменении заявления требуется новая соль. Повторная проверка выполняется незадолго до истечения соответствующего TTL или срока действительности подписи DNSSEC.

У этих требований нет смысла «отзыв мгновенно увидят все». Разные клиенты могут некоторое время располагать разными действующими поколениями сведений. Удалив старую запись слишком рано, оператор способен нарушить проверку у клиента, который ещё правомерно использует старую локальную информацию. Наличие новой записи само по себе не показывает, завершён ли переход.

RFC 8801 задаёт контекст доменов конфигурации: сведения DNS связаны с соответствующими параметрами сети, источником и следующим узлом, а дополнительная информация имеет идентификатор и срок действия. В реестре IANA для splitDnsClaims перечислены resolver, parent, subdomains, algorithm и salt. Реестр подтверждает согласованную структуру данных, а не наличие поддержки в определённом парке устройств.

Итак, главное достижение процедуры — не тайна как абсолютное свойство внутренней сети. Это возможность подтвердить частную область ответственности, не публикуя её подробный перечень. Сохраняются публичное имя резолвера, выбранная ширина согласия и обязательства по согласованию изменений. Именно эти оставшиеся элементы определяют, будет ли аккуратная криптографическая конструкция соответствовать тому решению, которое организация действительно хотела принять.