Стартавать Bind после OpenVPN

Можно, например, весьма элегантно забить на нее болт.
Или мешает что-то?

Шутки шутками конечно. Но хочется решение.
Пока вижу только решение в том, чтобы перезапускать Bind после OpenVPN, но это как-то не очень красиво.
В Debian 8 можно вроде средствами systemd расставить зависимости данных демонов друг от друга(в данном случае Bind от OpenVPN).
Но что в Debian 7 делать?

upstart, или даже openrc, или как там его... - Вполне должны справиться с этой тривиальщиной.

опенвпн умеет запускать скрипт при коннекте. Дернуть «rndc reload» не сложно.

named умеет искать новые интерфейсы, но не чаще раз в минуту (interface-interval 1).

А никаких шуток. Нет никаких причин вешать сервер слушать именно адрес туннельного интерфейса.

Попробовал, работает, вполне удобно.

Есть - адрес публичный, а ты владелец домена.

А как одно вытекает из другого?

Есть причины.
Например если нужно пустить dns-запросы через OpenVPN-сервер, а за клиентом сеть, то логично иметь на OpenVPN сервере кэширующий dns-сервер, чтобы немного уменьшить траффик с публичного адреса сервера.
Также удобно в созданной виртуальной сети обращаться к хостам по именам, а не по ip-адресам.
Да вообще много можно схем придумать.
Вопрос «зачем» пожалуй более риторический, чем linux-специфичный.

Неплохая теория по поводу процесса запуска изложена в статье на Habrahabr.ru: link

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

В Debian путь скорее всего немного другой: /etc/rc3.d/ Общая концепция заключаться в переименовании S02bind9, например, в S99bind9

dns-сервер (master или slave) должен быть доступен через публичный адрес, который можно получить через openvpn.

Общая концепция заключаться в переименовании S02bind9, например, в S99bind9

А если VPN отключить? И предположить, что интерфейсы tap/tun могут исчезнуть.

Т.е. ты предполагаешь, что сам сервер опенвпн с биндом не имеет белого адреса?
Как-то это экзотично.

Вопрос действительно более риторический, чем линукс-специфичный. Перед тем, как искать решение задачи, следует убедиться в существовании проблемы, ввиду которой эта задача возникла.
И мне все интереснее и интереснее, почему впн-клиентам нельзя ходить к бинду на тот же адрес, на который они идут к впн-серверу.
Кстати, у тебя в конфиге listen-on { any; };, или именно айпишник туннельного интерфейса? Если any, то такое поведение само собой странно, кмк.

Необходимость имеется в решении имеется.
В конфиге можно указать «any» или конкретный ip - ситуация не менятеся.

А, все-таки вот как.
Ну aseco выше подсказал простой фикс.

Согласен.

Еще в этом сообщении простое решение vel

Общая концепция заключаться в переименовании S02bind9, например, в S99bind9

Неправильное решение. Ты не задумывался над тем, что bind9 стартует одним из первых для того, чтобы следующие сервисы могли резолвить имена?

Чуть правильнее будет выставить старт OpenVPN перед bind9, но это тоже костыль.

ИМХО, верное решение озвучили выше: «путём настройки опроса интерфейсов».