Бронебойный DNS

Антон Карпов, toxa@cterra.ru

Спецвыпуск: Хакер, номер #051, стр. 051-044-3

# cd /usr/local/etc/djbdns/ext_tinydns/root

# vi data

.mydomain.ru:11.22.33.44:ns.mydomain.ru

.33.22.11.in-addr.arpa:11.22.33.44

@ank-pki.ru:11.22.33.44:mail.mydomain.ru:0

@ank-pki.ru:11.22.33.50:mx1.mydomain.ru:10

= host1.mydomain.ru:11.22.33.45

= host2.mydomain.ru:11.22.33.46

= host3.mydomain.ru:11.22.33.47

Cwww.mydomain.ru:host1.mydomain.ru

Cjabber.mydomain.ru:host2.mydomain.ru

# make

Как видно, каждая запись предваряется типом. Точка - SOA, @ - MX, = - A и PTR запись одновременно, C - CNAME. Очевидно, мы присвоили хосту 11.22.33.44 имя ns.mydomain.ru, он же - mail.mydomain.ru. Второй почтовый сервер, mx1.mydomain.ru, расположен по адресу 11.22.33.50 в этом же домене. host1-host3 - хосты, на которых крутятся сетевые сервисы. Jabber и www - алиасы, чтобы было понятно, что на host1 работает Apache, а на host2 - Jabberd. После правки конфигурационного файла набери make, чтобы программа tinydns-data перечитала его и обновила бинарный файл data.cdb. tinydns осуществляет поиск в бинарном файле, а не текстовых конфигурационных файлов, благодаря чему работает намного быстрее того же named. Кстати, файл можно не править вручную: в том же каталоге присутствуют скрипты для добавления записей. И тут у тебя просто начинает проситься наружу вопрос: "Как же dnscache и tinydns будут уживаться на одной машине, если за резолвом машины из mydomain.ru dnscache полезет в интернет, а машина - вот она, тут же". "Склеить" два демона можно таким образом:

# echo 11.22.33.44 %26gt; /usr/local/etc/djbdns/dnscache/root/servers/mydomain.ru

# echo 11.22.33.44 %26gt; /usr/local/etc/djbdns/dnscache/root/servers/33.22.11.in-addr.arpa

Замечу, что если провайдер не делегировал тебе обратную зону, то заморачиваться с in-addr.arpa вряд ли имеет смысл, так как в глобальном масштабе твой сервер будет не прав: он необоснованно считает себя ответственным за обратную зону.

Синхронизируем зону

Осталось только отдать нашу зону вторичному серверу. Как правило, чаще всего таким сервером бывает BIND. Конфигурируем axfrdns уже до боли знакомым образом:

# axfrdns-conf axfrdns dnslog /usr/local/etc/djbdns/axfrdns /usr/local/etc/djbdns/tinydns 11.22.33.44

Добавился новый аргумент - путь к месту расположения конфигурационных файлов tinydns. Не пугайся, что axfrdns слушает на том же интерфейсе, что и tinydns: он bind’ит порт 53/tcp, тогда как tinydns - 53/udp (named для трансфера зоны использует протокол TCP). Настроив BIND как slave, разрешим ему стягивать зону.

# cd /usr/local/etc/djbdns/axfrdns

# echo '22.33.44.55:allow,AXFR="mydomain.ru"' %26gt; tcp

# echo ":deny" %26gt;%26gt; tcp

# make

Вот так и была установлена переменная AXFR для хоста 22.33.44.55 (это адрес вторичного сервера) в значение "mydomain.ru". Это значит, что axfrdns позволит передачу соответствующей зоны машине 22.33.44.55.

# ln -s /usr/local/etc/djbdns/axfrdns /var/service

Ну а что если твой slave тоже использует tinydns? Например, если ты отвечаешь и за первичный, и за вторичный серверы. Тогда синхронизировать зоны можно и без axfrdns. DJB предлагает не изобретать велосипед в виде 53/tcp, а использовать удобный и безопасный способ - rsync over ssh. Для чего потребуется всего три шага: