У меня есть несколько систем Windows в сети Linux с BIND9 DNS, а также домен активного каталога. Мы не используем контроллеры домена Windows для DNS. Чтобы гарантировать, что все системы зарегистрированы в DNS, я развернул сценарий для каждой системы, которая использует двоичный файл Windows nsupdate для регистрации систем Windows в BIND. Это хорошо работает для настольных и портативных компьютеров и запускает изменение состояния сети.
Проблема здесь в том, что если ключ TSIG скомпрометирован на этих рабочих станциях, любая внутренняя запись может быть обновлена или удалена. Я смягчил это, установив сценарий и ключевые файлы для чтения только учетной записью SYSTEM, а все системы являются FDE с загрузочным контактом.
Имена хостов в организации следуют повторяемому соглашению, и рабочие станции всегда начинаются с W. Есть ли способ ограничить ключ хоста в BIND9 только обновлением или добавлением хостов с этим префиксом?
Я бы не хотел создавать еще одну зону для изоляции ключей tsig рабочей станции от остальных служб учетной записи, но это будет мой следующий вариант.
Вы можете настроить детальный ACL-контроль того, какой ключ может обновлять какие записи.
Это достигается с помощью update-policy заявление вместо allow-update, видеть BIND руководство.
update-policy { grant KEYNAME name RECORDNAME; ... };
ключ KEYNAME должен быть установлен на машине, которая обновляет RECORDNAME. Это еще более детальное поведение, которое вы просили. Вы также можете использовать подстановочные знаки, т.е. W* вместо RECORDNAME, и это должно работать точно так, как вы указали. Вы также можете дополнительно ограничить обновления, чтобы разрешить обновление только определенных типов DNS RR.
Традиционный allow-update поведение достигается с помощью zonesub тип правила.
Все это часто настраивается с помощью TSIG / GSS вместо PSK, но для этого требуется развертывание Kerberos. BIND даже может использовать аутентификацию, которую предоставляет встроенная в Windows программа обновления DNS, которая использует учетные записи домена их компьютеров (который использует тот же механизм, поскольку AD в любом случае основан на Kerberos).