bind искажает мой файл зоны каждый раз, когда выполняется обновление DNS. Если определение блока как константы невозможно, возможно ли иметь 2 или более файлов зоны, описывающих один домен? Намерение состоит в том, что один файл зоны предназначен для фиксированных RR, а другой - для динамических RR.
Наконец, если ничего из вышеперечисленного невозможно, можно ли возвращаться к исходному файлу зоны при каждом запуске DNS?
В крайнем случае, мне придется написать сценарий для ручного копирования или создания файла базовой зоны, а затем начать привязку. Но это не похоже на правильный способ сделать это.
Да, у вас может быть два файла для одной зоны. Вдобавок предлагаю делать все динамические обновления в субдомене. Комбинируя оба этих фактора, вы можете изолировать все машинные правки.
Добавьте это в конец файла зоны:
$INCLUDE dynamic-zone-file.conf dyn.example.com
Все динамические обновления затем будут отправляться в dynamic-zone-file.conf. Этот файл должен существовать и быть доступным для записи named пользователь.
Дайте определение «калечить». Если вы имеете в виду «перезаписать», тогда да, BIND должен перезаписывать файл зоны каждый раз, когда вы делаете обновление. Моя политика всегда заключалась в том, что после того, как файл зоны был открыт для динамических обновлений, он никогда больше не изменялся вручную, и вам приходилось использовать механизм автоматического обновления, чтобы что-то делать (много nsupdate вызовы или просто используйте настроенный нами API веб-интерфейса).
Чтобы ответить на другие ваши вопросы:
"возможно ли иметь 2 или более файла зон, описывающих один домен?" - правильным термином для «домена» в BIND является «зона», поэтому, если мы перепишем ваш вопрос так, чтобы он был «возможно ли иметь 2 или более файлов зоны, описывающих одну зону?», ответ станет довольно очевидным. Имейте две отдельные зоны, как описано в mghocke, если вам нужно что-то подобное.
"возможно ли возвращаться к исходному файлу зоны каждый раз при запуске DNS?" - Конечно, просто пусть ваш сценарий запуска DNS скопирует файл базовой зоны на место. Нет лучшего способа сделать это, потому что это не то, что кто-либо когда-либо хотел бы делать - принимать динамические обновления, а затем выбрасывать их каждый раз при перезапуске DNS-сервера. Одно предостережение при использовании этого метода заключается в том, что вам нужно будет обновить серийный номер при копировании файла базовой зоны, иначе ваши ведомые устройства не будут выполнять передачу зоны.
Мои экстрасенсорные способности подсказывают, что вы пытаетесь смешать ручное (прямое) редактирование файла зоны с динамическими обновлениями. Просто чтобы вы знали, это не сработает (в наивном случае) - рано или поздно вы попадете в гонку между динамическим обновлением и ручным редактированием файла, и динамическое обновление победит, что приведет к потеря вашего ручного обновления. Вам нужно будет замораживать и размораживать зону каждый раз, когда вы хотите редактировать (удачи, повсеместно применяя который один). Это причина моей политики «все изменения в динамических зонах должны выполняться через интерфейс DDNS».
У меня мы храним динамические обновления, содержащиеся в собственных зонах. Я не могу придумать, как поддерживать порядок в файле зоны, если он получает динамические обновления. Я не уверен, что вы пытаетесь сказать «возможно ли вернуться к исходному файлу зоны». Вы говорите, что вам не нужно, чтобы динамические обновления были постоянными между перезапусками BIND? Если это так, просто напишите сценарий, который копирует файл основной зоны, который вы храните и редактируете где-нибудь до запуска BIND.