У меня есть то, что, как я чувствую, в конечном итоге станет простой проблемой, однако я не вижу очевидной проблемы. hosts - Обновите серийный номер с новой временной меткой unix - повторно сохраните и перезапустите Bind. И, альт, отправляются уведомления, что зона была обновлена.
РЕДАКТИРОВАТЬ
Затем я получаю следующее в журнале
8377:Jun 12 14:12:57 OURSND named[25262]: zone example.com/IN: sending notifies (serial 1494611231)
КОНЕЦ РЕДАКТИРОВАНИЯ
Вот вопрос, почему не отправляются уведомления, когда я создаю зону и перезапускаю Bind? Почему мне нужно вернуться, отредактировать, повторно сохранить и перезапустить Bind, чтобы зона отображалась как «обновленная»? Я хочу, чтобы это происходило каждый раз в первый раз. Что я не вижу?
Считайте серийный номер номером версии. Вы (повторно) запускаете привязку, она проверяет номер версии в своем кэше данных по сравнению с номером версии в config (серийный номер). Если версия та же, зачем вообще все заново обрабатывать и зачем тратить пропускную способность сети, говоря вторичным серверам, что у вас есть зона (зоны) для передачи ...
Всегда обновляйте серийный номер. Единственное правило - он должен расти. Хорошо использовать временную метку unix или такой формат, как YYYYMMDDNN, где NN - номер редакции на этот день (нужно ли вам менять его более 99 раз в день?).
Проблема, как вы обнаружили, заключается в не забывая обновлять серийный номер при редактировании файла. Используйте некоторые файлы шаблонов, файлы данных и сценарии оболочки для создания процесса «сборки», в котором вы вносите свои изменения в данные, а затем говорите ему, чтобы он регенерировал файлы зоны, часть которых будет включать выпуск нового серийного номера , или даже перейти к (излишнему) веб-интерфейсу с панелью управления "поставщика услуг", такой как ISPConfig, где все данные будут в базе данных sql, а программа ispconfig автоматически создаст файл (ы) зоны.