Кратко

  • Выпущенная 2 сентября версия NSD 4.15.2 проверяет имя клиентского сертификата вместе с адресом и TSIG того же элемента списка доступа.
  • Исходное сообщение описывает отказ законному клиенту при наличии второй разрешённой идентичности. Тесты проверяют два допустимых сертификата, но не воспроизводят все сочетания условий исходной установки.

Отказ неизвестному клиенту — лишь половина проверки доступа. Вторая половина состоит в том, чтобы разрешённый клиент продолжал получать данные после добавления другого разрешённого клиента. Исправление NSD показывает, как эта простая обязанность может потеряться между отдельными проверками.

В сообщении от 24 июля пользователь описал тест с NSD 4.14.0 из EPEL на RHEL 9.8 в роли первичного сервера. Два вторичных сервера работали на другом ПО. У каждого были отдельные адрес и имя сертификата, а две разрешающие записи использовали общий ключ TSIG.

Журнал показывал успешное установление TLS, принятую проверку TSIG и совпадение с первым именем сертификата. Затем следовало несовпадение со вторым именем и отказ в передаче зоны. При одной записи передача работала. Это описание тестовой среды с частными адресами, а не карта публичной сети, пережившей массовый сбой.

28 августа сопровождающий сообщил о воспроизведении и исправлении ошибки. В объявлении версии 4.15.2 от 2 сентября прямо указана проверка условий в пределах одной записи. При проверке 8 сентября страница загрузок по-прежнему называла 4.15.2 текущей версией. Повторного теста автора сообщения после выпуска в обсуждении нет; восстановление работы всех пользователей из этой цепочки не следует.

Где заканчивается одна разрешённая комбинация

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

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

При смене сертификата старое и новое имена могут некоторое время сосуществовать. Клиент должен выполнить относящийся к нему набор требований, а не оказаться сразу двумя разными клиентами. Именно поэтому зелёный индикатор TLS недостаточен: защищённый канал уже создан, но передача содержимого зоны ещё может быть запрещена.

Два успешных случая не равны проверке всех условий

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

Однако две сертификатные записи теста разрешают любой источник IPv4 и используют NOKEY. Исходное сообщение описывало разные адреса и общий TSIG. Следовательно, тест проясняет поведение нескольких идентичностей, но не перебирает все комбинации адреса, ключа и имени из реальной конфигурации. Для этой статьи изучены код и условия теста; NSD не запускался, независимого воспроизведения не проводилось.

В тесте есть и отдельная запись, разрешающая передачу с TSIG через обычный TLS или TCP. Это явно заданная альтернатива, а не доказательство нового обхода защиты. Как объясняет RFC 9103, аутентификация и конфиденциальность различаются: сам по себе TSIG не шифрует содержимое зоны. Защита всей группы передачи требует политики для каждой существенной связи, а не одной работающей зашифрованной сессии.

Не следует переносить на это исправление и обозначение CVE-2026-12490. Согласно уведомлениям NLnet Labs о безопасности, тот отдельный обход требования сертификата был опубликован в июне и исправлен в 4.14.3. Его номер и диапазон затронутых версий не описывают автоматически рассматриваемый отказ при нескольких именах. Здесь не установлены новая эксплуатация, число пострадавших заказчиков или полная матрица уязвимых версий.

Принцип точных, проверяемых на месте условий безопасности, который формулирует Lu Heng, применим к этому случаю в ограниченном смысле: явно определить разрешённое сочетание требований, не ослабляя их незаметно ради успешного ответа. Это аналитическое применение принципа автором статьи, а не оценка NSD, приписываемая Lu Heng.