История изменений

Если slave будет запускаться при выключенном master'е, он не получит зоны

Во-первых, у слэйва есть кэш старой версии зоны. Который он регулярно обновляет, связываясь с мастером и опрашивая серийник зоны. Если мастер недоступен - слейв будет использовать старую версию зоны из кэша. Угу.

Во-вторых, мастер рассылает нотифи если зона на нём изменилась, а также уведомления при своём старте, поэтому ситуация «слейв поднялся а мастер недоступен» при ПРАВИЛЬНОЙ настройке и ПРАВИЛЬНОМ ведении зон практически никогда не приведет к ошибке.

Пять зон на пяти серверах, когда каждая зона лежит на каждом из 5 серверов, на одном в мастере на остальных в слейвах, доступность хостов от 0.9 до 0.1 (это мои компьютеры и ноутбуки), и зоны не разу не «разбежались».

мониторить постоянно логи на slave-сервере на отсутствие ошибок трансфера зоны

... не нужно. Достаточно скрипта, который будет сравнивать серийники зон на мастере и слейве. Примерно в 20 строчек на баше, включая комментарии.

Если slave будет запускаться при выключенном master'е, он не получит зоны

Во-первых, у слэйва есть кэш старой версии зоны. Который он регулярно обновляет, связываясь с мастером и опрашивая серийник зоны. Если мастер недоступен - слейв будет использовать старую версию зоны из кэша. Угу.

Во-вторых, мастер рассылает нотифи если зона на нём изменилась, а также уведомления при своём старте, поэтому ситуация «слейв поднялся а мастер недоступен» при ПРАВИЛЬНОЙ настройке и ПРАВИЛЬНОМ ведении зон практически исключена.

Пять зон на пяти серверах, когда каждая зона лежит на каждом из 5 серверов, на одном в мастере на остальных в слейвах, доступность хостов от 0.9 до 0.1 (это мои компьютеры и ноутбуки), и зоны не разу не «разбежались».

мониторить постоянно логи на slave-сервере на отсутствие ошибок трансфера зоны

... не нужно. Достаточно скрипта, который будет сравнивать серийники зон на мастере и слейве. Примерно в 20 строчек на баше, включая комментарии.