В настоящее время выполняется BIND на RHEL 5.4, и я ищу более эффективный способ перенаправления DNS на сервер приманки для большого (30 000+) списка запрещенных доменов.
Нашим текущим решением для этого требования является включение файла, содержащего главную декларацию зоны для каждого заблокированного домена, в named.conf. Впоследствии каждое из этих объявлений зон указывает на один и тот же файл зоны, который разрешает все хосты в этом домене на наши серверы-приманки. ... в основном это позволяет нам перехватывать любые попытки «звонков домой» вредоносного ПО, которое может проникнуть во внутренние системы.
Проблема с этой конфигурацией заключается в большом количестве времени, необходимом для загрузки всех 30000+ доменов, а также на управление самим файлом конфигурации списка доменов ... если в этот файл закрадываются какие-либо ошибки, сервер BIND не запустится, что приведет к Автоматизация процесса немного пугает. Поэтому я ищу что-то более эффективное и потенциально менее подверженное ошибкам.
include "blackholes.conf";
zone "bad-domain.com" IN { type master; file "/var/named/blackhole.zone"; allow-query { any; }; notify no; };
$ INCLUDE std.soa
@ NS ns1.ourdomain.com.
@ NS ns2.ourdomain.com.
@ NS ns3.ourdomain.com.IN A 192.168.0.99
* В А 192.168.0.99
Не удалось найти хороший способ избавиться от необходимости загружать каждый домен в его собственную зону, но использование следующей команды rndc устраняет проблему сбоя сервера в случае неправильной записи.
rndc reconfig
Полный перезапуск / перезагрузка сервера все равно приведет к сбою запуска.
Вы рассматривали альтернативу BIND? Я еще не использовал их, но есть альтернативы MySQL с веб-интерфейсами, такие как PowerDNS с Poweradmin. Это может сделать обновления менее подверженными ошибкам и рискованными. PowerDNS даже имеет инструмент для преобразования файла зоны BIND в SQL для миграции.
Кроме того, могу я спросить, общедоступен ли этот список? Меня это очень интересует.
В теория вы можете избежать медленной загрузки, сделав список черных дыр частью корневого файла подсказок (например, через $INCLUDE), а затем заменив этот файл hint к 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: Я не проверял это.
редактировать : Извините, я плохо прочитал ваш вопрос. Предлагаю то же, что и вы. Может, можно включить файл, созданный из базы данных?
У меня есть файл 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; }; };
Мне не нужно определять его в файле зоны, он общий.