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

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

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

- Создаем на slave-сервере отдельного пользователя, который будет владеть базой имен (файл data.cdb), которая подлежит синхронизации. Ничто не мешает использовать рабочий логин:

# chown toxa /usr/local/etc/djbdns/tinydns/root/data.cdb

# chown toxa /usr/local/etc/djbdns/tinydns/root

На той же машине создадим заведомо некорректный файл data, чтобы после набора там make случайно не переписать синхронизированный data.cdb:

# echo thisserverisslave %26gt; /usr/local/etc/djbdns/tinydns/root/data

На первичном сервере добавляем в начало файла /usr/local/etc/djbdns/tinydns/root/Makefile строчки:

sync: data.cdb

rsync -az -e ssh data.cdb toxa@22.33.44.55:/usr/local/etc/djbdns/tinydns/root/data.cdb

Теперь при внесении изменений на первичном сервере и при последующем обновлении data.cdb командой make данные обновятся и на вторичном сервере. Так как используется rsync (естественно, пакет rsync не входит в базовую поставку FreeBSD, поставь его из порта net/rsync). По Сети будут переданы лишь изменения, а не весь data.cdb. Если ты настроишь ssh-авторизацию по ключам, у тебя даже пароля не попросят :).

Что получили в результате? Dnscache знай себе кеширует запросы из локальной сети, tinydns спокойно и размеренно рассказывает внешним машинам о хостах нашего домена, ну а axfrdns помогает тем несчастным, которые еще используют BIND, стягивать нашу name-зону. Теперь ты можешь смело оставить свой сервер жить своей жизнью - патчить djbdns тебе не придется. Ну а если возникнут какие проблемы, знай, что www.google.com не собирается менять свой URL ;).

Порядок делегирования зоны

Очень важно помнить последовательность добавления вторичных серверов и не совершать популярной ошибки под названием lame delegation. Правильный порядок действия таков.

1. Настроить вторичный dns-сервер на получение зоны c первичного.

2. Разрешить на первичном сервере трансфер зоны вторичным dns-сервером. В случае BIND эта процедура включает в себя правку конфигурационных фалов named.conf на обоих серверах, открытие портов 53/tcp на соответствующие хосты, просмотр логов named на наличие ошибок и т.д. В случае tinydns эта процедура сводится к прописыванию одной строчки в Makefile. Если что не так, rsync тут же выдаст на консоль диагностические ошибки.

3. Добавить в конфиг зоны первичного сервера NS-запись, указывающую на новый вторичный сервер.

4. Если новый вторичный сервер входит в обслуживаемую зону, добавить соответствующую A-запись.

5. Сообщить вышестоящему регистратору о новом сервере имен для своей зоны. Как правило, это делается через web-формы администрирования соответствующего держателя вышестоящего домена (domainpeople.com, nic.ru, etc).

Очень часто забывают выполнить третий пункт, и тогда информация на вышестоящих серверах имен о NS'ах твоей зоны не совпадает с информацией о таковых, полученных непосредственно с них самих. Вся беда в том, что ответ твоих name-серверов считается авторитетным, тогда как ответ вышестоящих - нет. Это и называется lame delegation: dns-сервер является вторичным для зоны, но сам об этом не знает.