VNC или коммерческие предложения (GoToAssist и т.д.), вероятно, являются Вашим лучшим выбором. Они обычно всегда спрашивают разрешение от удаленного пользователя прежде, чем позволить соединению продолжаться. Просто обратите внимание, что с VNC существует несколько вариантов, и от тех UltraVNC кажется популярным. Эти варианты также имеют отличающиеся уровни экранного сжатия, таким образом, необходимо действительно выдержать сравнение, который является лучшим для случая, поскольку соединение VPN (по Интернету) имеет тенденцию представлять партию задержки, и это объединилось с узкой пропускной способностью, может действительно сделать опыт более трудным, чем это должно.
Rdesktop (или соединяющийся с обычными методами RDP) не действительно подходит, если Вы хотите сделать, демонстрация экрана как входящий в систему удаленной машины требует a) ввода учетных данных пользователя (который из соображений безопасности Вы никогда не должны спрашивать от пользователя), и b) она блокирует локальный рабочий стол, когда Вы подключены с (если это не Windows Server ОС).
Редактирование: Извините я не читаю хорошо Ваш вопрос. Я предлагаю то же самое как Вы. Возможно, можно ли включать файл, сгенерированный от базы данных?
У меня есть dropDomain файл с:
$TTL 3600 ; 1 hour
@ IN SOA xxxxxxxx.fr. dnsmaster.xxxxxxxx.fr. (
2009112001 ; serial 20yymmdd+nn
900 ; refresh (15 minutes)
600 ; retry (10 minutes)
86400 ; expire (1 day)
3600 ; minimum (1 hour)
)
NS dns1.xxxxxxxx.fr.
NS dns2.xxxxxxxx.fr.
MX 0 smtp.xxxxxxx.fr.
* A 127.0.0.1
; vim:filetype=bindzone
Затем я просто добавляю домены в своем списке в named.conf.local:
# Master pour les zones que l'on ne veut plus resoudre (pirates, virus, prise en main a distance...)
zone "zzzzzzz.com" { type master; file "/etc/bind/dropDomain.tld"; allow-query { any; }; };
zone "yyyyyyy.com" { type master; file "/etc/bind/dropDomain.tld"; allow-query { any; }; };
zone "ttttttt.com" { type master; file "/etc/bind/dropDomain.tld"; allow-query { any; }; };
Я не должен определять его в зональном файле, это универсально.
В теории можно избежать медленного времени загрузки путем создания части черного списка корневого файла подсказок (например, через $INCLUDE
) и затем изменяя тот файл от того, чтобы быть a hint
к a master
. Тот последний бит необходим для препятствования серверу загрузка реальные корневые подсказки из Интернета.
например, в named.ca
:
a.root-servers.net. IN A ....
m.root-servers.net. IN A ....
$INCLUDE blackhole.zone
и затем в blackhole.zone
:
$ORIGIN example.com.
@ IN 192.168.0.99
* IN 192.168.0.99
$ORIGIN example.net.
@ IN 192.168.0.99
* IN 192.168.0.99
; ad-infinitum
Нет никакой реальной потребности в записях NS или отдельная zone
операторы для каждой помещенной в черный список зоны - Вы эффективно вставляете поддельные авторитетные данные в свою локальную копию корневой зоны. Просто удостоверьтесь, что Вы иногда загружаете реальную корневую зону!
Затем просто пойдите с предложением @syn выполнения named-checkzone
перед каждой перезагрузкой и/или перезапуском.
NB: я не протестировал это.
Вы рассмотрели альтернативу BIND? Я еще не использовал никого, но существует MySQL управляемые альтернативы с сетью frontends, такие как PowerDNS с Poweradmin. Это могло бы сделать обновления менее подверженными ошибкам и опасными. PowerDNS даже имеет инструмент для преобразования файла зоны BIND в SQL для миграции.
Кроме того, я могу спросить, общедоступен ли тот список? Я очень интересуюсь этим сам.
Не нашли хороший способ устранить необходимость загрузить каждый домен в его собственной зоне, но использование следующей команды rndc устраняет беспокойство того, чтобы заставлять сервер перестать работать в случае уродливой записи.
rndc reconfig
Полное на перезапуске/перезагрузке сервера все еще приведет к отказу запуститься.
named-checkzone
, чтобы видеть, обнаруживаются ли некоторые ошибки. В противном случае затем примените конфигурацию к серверу DNS. – Dom 7 April 2010 в 13:25