Обеспечение перенаправления DNS к серверу ловушки для известных плохих доменов

VNC или коммерческие предложения (GoToAssist и т.д.), вероятно, являются Вашим лучшим выбором. Они обычно всегда спрашивают разрешение от удаленного пользователя прежде, чем позволить соединению продолжаться. Просто обратите внимание, что с VNC существует несколько вариантов, и от тех UltraVNC кажется популярным. Эти варианты также имеют отличающиеся уровни экранного сжатия, таким образом, необходимо действительно выдержать сравнение, который является лучшим для случая, поскольку соединение VPN (по Интернету) имеет тенденцию представлять партию задержки, и это объединилось с узкой пропускной способностью, может действительно сделать опыт более трудным, чем это должно.

Rdesktop (или соединяющийся с обычными методами RDP) не действительно подходит, если Вы хотите сделать, демонстрация экрана как входящий в систему удаленной машины требует a) ввода учетных данных пользователя (который из соображений безопасности Вы никогда не должны спрашивать от пользователя), и b) она блокирует локальный рабочий стол, когда Вы подключены с (если это не Windows Server ОС).

3
задан 6 April 2010 в 23:36
4 ответа

Редактирование: Извините я не читаю хорошо Ваш вопрос. Я предлагаю то же самое как Вы. Возможно, можно ли включать файл, сгенерированный от базы данных?

У меня есть 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; }; };

Я не должен определять его в зональном файле, это универсально.

0
ответ дан 3 December 2019 в 08:27
  • 1
    Как Вы заявили, это - тот же метод I' m в настоящее время использующий (который достаточно странно сгенерирован от бэкенда базы данных). " потенциал errors" часть имеет дело с данными, ввел в DB неправильно... I' ve заставил проверки работоспособности на месте заботиться о большей части из этого, но на что я надеялся, был способ загрузить " помещенный в черный список domains" в конфигурацию где-нибудь способом это wouldn' t останавливают инициализацию сервера, если была плохая запись это didn' t выполняют ограничения RFC. –  syn- 7 April 2010 в 01:06
  • 2
    Я don' t знают ограничения RFC, но можно подготовить целую конфигурацию DNS и передать named-checkzone, чтобы видеть, обнаруживаются ли некоторые ошибки. В противном случае затем примените конфигурацию к серверу DNS. –  Dom 7 April 2010 в 13:25

В теории можно избежать медленного времени загрузки путем создания части черного списка корневого файла подсказок (например, через $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: я не протестировал это.

0
ответ дан 3 December 2019 в 08:27

Вы рассмотрели альтернативу BIND? Я еще не использовал никого, но существует MySQL управляемые альтернативы с сетью frontends, такие как PowerDNS с Poweradmin. Это могло бы сделать обновления менее подверженными ошибкам и опасными. PowerDNS даже имеет инструмент для преобразования файла зоны BIND в SQL для миграции.

Кроме того, я могу спросить, общедоступен ли тот список? Я очень интересуюсь этим сам.

0
ответ дан 3 December 2019 в 08:27
  • 1
    установки VDI мне нравится мысль backending все это с базой данных, но на данный момент я нашел свое решение. Я обновлю сообщение с тем, что мы делаем теперь. Что касается обеспечения списка, к сожалению, который не находится в общественном достоянии. ;) –  syn- 10 August 2010 в 05:38

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

rndc reconfig

Полное на перезапуске/перезагрузке сервера все еще приведет к отказу запуститься.

0
ответ дан 3 December 2019 в 08:27

Теги

Похожие вопросы