Если я сталкивался с этим, я был бы:
mv /usr/sbin/openvpn /usr/sbin/openvpn.binary
echo "#!/bin/sh
exec /usr/sbin/openvpn.binary --float $*" >/usr/sbin/openvpn
chmod 755 /usr/sbin/openvpn
и затем посмотрите, работают ли существующие инструменты все еще. Это должно заставить это передавать - плавание все время. Можно добавить код к новому 'openvpn.sh' сценарию, если Вы только хотите передать его для определенных соединений (возможно, $ эха* | grep client.conf).
type master;
делает то, что Вы хотите. если 172.16.1.1
авторитетный сервер, запросы не перейдут к корневым серверам. Несуществующие записи приведут к состоянию NXDOMAIN.
Если Вы хотите мешать всем запросам передать корневым серверам, то необходимо выключить рекурсию. см.: http://www.zytrax.com/books/dns/ch6/#authoritative
У вас могут быть настроены клиенты для использования 172.16.100.1 в качестве основного DNS-сервера.
Используйте опцию «Переадресация» в BINDO 172.16.1.1 на вашем DNS-сервере в 172.16.100.1.
options {
[Your other options here]
forwarders {172.16.1.1;};
}
Первый авторитетный ответ будет возвращен (выигрывает). Таким образом, ваши клиенты выглядят
что-нибудь .foo
Ваш DNS-сервер предоставит авторитетный ответ (либо действительная запись, либо nxdomain). Если ваш клиент ищет www.google.com - ваш DNS-сервер не может предоставить ответ, и в результате будет пересылать запрос на 172.16.1.1.
Я использую пользовательские TLD для всего на моих внутренних сетях. С вышеуказанной конфигурацией он работает без каких-либо проблем и до сих пор позволяет публичному разрешению DNS через опцию пересылки.