У меня есть то, что, как мне кажется, в конечном итоге станет простой проблемой, однако я не вижу очевидной проблемы.
Вот примерный поток, прежде всего, чтобы лучше понять, как все происходит по порядку - обратите внимание, что это инфраструктура, которая уже существует, и порядок операций должен оставаться неизменным:
Теперь ... Между шагами 1 и 2 мы начинаем видеть это (очевидно, потому что домена еще нет в нашей системе:
Jun 12 15:32:40 DNSSERVER named[25262]: client 230..xxx.xxx.xx#61333 (example.com): query (cache) 'example.com/SOA/IN' denied
Далее я создаю файл зоны /var/lib/bind/example.com.hosts:
$ttl 38400
example.com. IN SOA ns1.ourdnsserver.com. some.email.com. (
1494611262
10800
3600
604800
38400 )
example.com. IN NS ns1.ourdnsserver.com.
example.com. IN A 40.xx.xx.xx
www.example.com. IN A 40.xx.xx.xx
mail.example.com. IN A 173.xx.xx.xx
webmail.example.com. IN A 173.xx.xx.xx
example.com. IN MX 10 mx1.server.com.
example.com. IN MX 20 mx2.server.com.
После этого вставляю зону в конфигурацию /etc/bind/ named.conf.local:
zone "example.com" {
type master;
file "/var/lib/bind/example.com.hosts";
};
Потом делаю перезапуск sudo service bind9 restart
После этого я все еще получаю
Jun 12 15:32:40 DNSSERVER named[25262]: client 230..xxx.xxx.xx#61333 (example.com): query (cache) 'example.com/SOA/IN' denied
Что мне нужно сделать, чтобы решить эту проблему, так это редактировать мой файл /var/lib/bind/example.com.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 автоматически создаст файл (ы) зоны.