Кратко

  • RFC 9103 закрывает сбор содержимого зоны пассивным наблюдателем открытого канала передачи. Он не скрывает все сведения о серверах, время и объём трафика, перечисление DNSSEC и обычные авторитативные ответы.
  • Проверяемое утверждение о XoT требует отдельных квитанций: личность primary, допуск к зоне, обязательный TLS, завершение передачи, принятие реплики, единая политика transfer group и последующее хранение.

Наблюдателю не требовалось быть клиентом

Primary может принимать AXFR только от разрешённых адресов и проверять TSIG. Это отсекает посторонний запрос. Но если ответ разрешённому secondary идёт по открытому TCP, наблюдатель на маршруте не должен обходить ACL или добывать общий ключ. Он читает те же записи, которые получает законный адресат.

RFC 9103 устраняет именно такой путь. Документ Standards Track IETF, опубликованный в августе 2021 года, определяет XFR over TLS для полного AXFR и инкрементального IXFR. Один поток репликации способен раскрыть плотный набор имён, адресов и связей; убрать из него открытый текст — существенный результат.

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

Поэтому корректно сказать: пассивный наблюдатель проверенного канала больше не увидел payload. Фраза «зона стала приватной» потребовала бы других доказательств.

TSIG и TLS отвечают на разные вопросы

RFC 8945 задаёт TSIG для аутентификации DNS-сообщений общим секретом и контроля целостности. RFC 5936 применяет TSIG при авторизации клиентов передачи. Однако TSIG ничего не шифрует. Подлинное сообщение может оставаться читаемым на маршруте.

TLS защищает канал. Secondary должен удостоверить primary по строгому профилю, а primary — проверить право клиента через mutual TLS либо IP ACL вместе с TSIG/SIG(0). Strict TLS даёт аутентификацию сервера и конфиденциальность канала; mTLS добавляет аутентификацию клиента; TSIG подтверждает происхождение данных. Эти свойства нельзя сворачивать в один флаг.

Установленное TLS-соединение не разрешает копировать любую зону. Один канал может обслуживать несколько запросов, а ACL обычно применяется к конкретному XFR после установления соединения. Доступный порт, успешный handshake и разрешение на одну зону — разные события.

Политику определяет самый слабый маршрут

Все primaries и secondaries, участвующие в обмене, RFC 9103 называет transfer group. Для защиты группы каждый путь AXFR и IXFR должен использовать XoT. Один устаревший secondary, аварийный маршрут в открытом виде или незашифрованный участок после TLS proxy сохраняет наблюдателя.

Opportunistic TLS не даёт нужной гарантии. Он способен продолжить работу без надёжно установленной личности сервера или откатиться к открытому тексту. Для обещания «зона не передаётся открыто» такая неопределённость неприемлема.

Следует различать и fallback. Переход с IXFR на AXFR внутри того же аутентифицированного TLS увеличивает объём, но не обязан менять конфиденциальность. Откат с TLS на открытый TCP отменяет само утверждение. То же происходит, если proxy завершает защищённый канал слишком рано.

Часть условий легко проверить отрицательными запросами: без TSIG, с запрещённого адреса или по открытому транспорту. Сложнее доказать, что каждый secondary отвергает неподписанные данные, использует strict profile и защищает дальнейшую репликацию. Координация и принуждение общей политики находятся вне RFC.

После доставки меняется владелец контроля

Пусть всё выполнено правильно: primary распознан, secondary допущен, TLS 1.3 включён, IXFR завершён, новый serial принят. Пассивный наблюдатель потерял содержимое. Зато копия зоны оказалась в другой административной среде.

Она может храниться в zone file, journal, базе, snapshot, backup или support log. К ней имеют доступ внутренние люди и системы. Она может уйти следующим secondaries. Авторитативный DNS продолжит отвечать на публичные запросы.

Это не поломки TLS, а последствия успешной репликации. Запись контроля должна охватывать места хранения, локальный доступ, сроки backup и log, последующие направления и процедуру удаления peer. Отзыв сертификата или TSIG-ключа остановит будущую передачу, но не вернёт ранее выданный файл.

ZONEMD показывает ещё одну границу. RFC 8976 описывает digest для проверки самостоятельного объекта зоны. Он дополняет XoT и не зависит от канала. Digest не скрывает данные в пути; TLS не доказывает правильность, актуальность или надлежащее человеческое одобрение содержимого.

Публичный DNS продолжает отвечать

Перехват передачи и перечисление зоны — ортогональные пути. NSEC может позволить пройти подписанную зону. NSEC3 хеширует owner names, чтобы усложнить такую работу, но не превращает XoT в всеобщее сокрытие. Обычные авторитативные запросы по-прежнему возвращают предназначенные для публикации записи.

Необходимо удерживать две мысли одновременно. Публичность части DNS не оправдывает открытую массовую репликацию. Шифрование репликации, в свою очередь, не делает публичные записи тайными. XoT закрывает один особенно удобный канал сбора.

Восемь строк квитанции

Область фиксирует зону, версию политики, transfer group и ответственных. Личность primary — имя аутентификации или SPKI pin, сертификат, версию TLS и endpoint. Допуск secondary — mTLS либо ACL с TSIG/SIG(0), решение по зоне и тесты отказа.

Транспорт описывает AXoT/IXoT, запрет открытого текста, fallback и границы proxy. Завершение — запрошенный и принятый serial, переход IXFR→AXFR и ошибки. Хранение реплики — storage, access, backups, logs и onward peers.

Остаточная видимость включает обычные запросы, NSEC/NSEC3, связи endpoint и сигналы трафика. Повторная проверка запускается изменением сертификата, ключа, ACL, proxy, secondary, topology, signing policy или оператора.

TLS handshake доказывает свойства канала. TSIG — свойства сообщения. Принятый serial — состояние реплики. Ни одно из них отдельно не доказывает конфиденциальность всех копий.

Источники