Конфигурирование ограничений перенаправления динамических обновлений с использованием ключей TSIG
Динамическим обновлениям разрешено копирование зонного файла на первичный авторитетный name-сервер только потому, что он является "writable". При этом автоматически не предполагается, что только первичный авторитетный name-сервер может принимать запросы динамического обновления. В BIND 9.1.0 и более поздних версиях разрешается вторичным name-серверам принимать запросы динамического обновления и перенаправлять их первичному авторитетному name-серверу. В данном сценарии, если не существует ограничений, основанных на идентификации хостов, с которых вторичный name-сервер может перенаправлять такие запросы динамического обновления, это эквивалентно обходу ограничений динамического обновления, указанным в первичном name-сервере, потому что запрос может исходить с любого хоста к вторичному name-серверу и перенаправляться на первичный name-сервер. Для решения данной проблемы было добавлено новое подутверждение allow-update-forwarding в версии BIND, которые имеют возможность перенаправления динамических обновлений. Пример такого allow-update-forwarding утверждения с использованием TSIG-ключей следующий:
zone "example.ru" { type slave; file "backupdb.example.ru"; allow-update-forwarding { key {dhcp-server.example.ru.}; }; };
