Первоначально документация Dan'а не содержала никаких рецептов для решения обычных проблем. Впоследствии, он очень расширил свою документацию и я предлагаю, чтобы вы пошли туда и прочитали её.
Этот FAQ неофициальный, и рассматривает другие, более экзотические вопросы, такие как вопросы о IPv6 и о том, как запустить dnscache и tinydns на одном IP.
Как я могу внести вклад в этот FAQ?
Просто отправьте письмо на felix-dnsfaq@fefe.de. Пожалуйста, не посылайте только вопросы, посылайте ответы. Я не автоматическая служба поддержки для djbdns, несмотря на то, что я предлагаю платную поддержку. Да, меня зовут Felix von Leitner, и на сегодняшний момент я единственный разработчик этого FAQ. Обратная связь приветствуется. E-mail адрес не является ссылкой (чтобы помешать тупым spam-ботам найти его).
djbdns — это DNS package, написанный DJ Bernstein который состоит из
В djbdns resolver и сервер разделены, чтобы обеспечить лучшую
безопасность и гибкость, но когда кто-то пытается запустить их оба на одном IP-адресе
(как это по умолчанию делается в BIND), он получает неустойчивую работу.
Как я могу запустить resolver и сервер на одном IP?
Если кратко, то вы не можете этого сделать. Можно запустить dnscache на вашем ethernet IP-адресе и tinydns на 127.0.0.1 и затем настроить dnscache, так, чтобы он спрашивал tinydns об определенных зонах.
Вы можете запустить dnscache и tinydns на одном IP и порту, потому что это UDP-серверы. Ваша операционная система будет пересылать DNS-запрос одному из них, и вы не сможете никак повлиять на выбор. Tinydns будет отбрасывать все запросы, на которые не сможет ответить, поэтому каждый запрос, отданный tinydns, по зонам, для которых он не полномочен, будет отброшен.
Клиент пошлет тот же запрос еще раз через несколько секунд, поэтому для пользователя будет казаться, что сеть работает медленно. Если следующий запрос опять попадет к tinydns, таймаут окажется еще большим. Если вы хотите получить ответ от tinydns, но запрос попадает к dnscache, вы получите "server failure".
Вы должны решить: должен ли кэширующий resolver быть доступен вашим клиентам? Если так, запустите dnscache на наружном IP, tinydns на 127.0.0.1 и укажите dnscache консультироваться с tinydns для адресов, для которых он полномочен. Посмотрите также Split Horizon.
Это решение имеет недостаток — dnscache никогда не будет возвращать
authoritative ответов (признаком этого является бит в пакете DNS-ответа). Это не имеет значения
для большинства клиентов, но все же технически не совсем корректно. Например,
регистратор вашего домена может быть недоволен этим. (Спасибо Brian Kifiak
за то, что указал на это). НЕ ДЕЛАЙТЕ ЭТО НА PRODUCTION DNS-СЕРВЕРАХ!
Правильные resolver'ы (например, dnscache) не принимают non-authoritative ответы.
(Здесь очевидно имеется в виду ситуация, когда dnscache работает в обычном режиме,
а не "forward only", т.е. когда напрямую делает запросы к NS-серверам, а не пересылает
запросы на resolver провайдера — прим. перев.).
Лучшим решением будет использование IP-псевдонимов, например, на Linux вы можете просто
назначить несколько IP-адресов виртуальным интерфейсам.
Могу я использовать djbdns без daemontools?
Да.
Много людей пугаются инструкции по установке daemontools и поэтому боятся попробовать djbdns. DJ Bernstein не рекомендует это, но вы можете использовать различные DNS-сервера (из состава djbdns) и dnscache без использования svscan и supervise. Этот FAQ только описывает, как избежать запуска "svscan", т.е. вы все равно должны будете установить daemontools для использования envuidgid и softlimit, которые все же полезны, и используются в стартовых скриптах djbdns.
Просто следуйте инсталляционным инструкциям, и вы получите скрипт оболочки /service/tinydns/run. Этот скрипт запустит сервис (но он не перейдет в фоновый режим ("fork into the background"), так что для стартового скрипта в стиле System V вы должны использовать что-то вроде этого):
case "$1" in
start) echo "Starting tinydns."
exec /service/tinydns/run &
echo $! > /var/run/tinydns.pid
;;
stop) echo "Shutting down tinydns."
kill `cat /var/run/tinydns.pid`
rm -f /var/run/tinydns.pid
;;
*) echo "Usage: $0 {start|stop}"
exit 1
esac
exit 0
Tobias Oetiker создал расширенный стартовый скрипт.
Если вы не хотите использовать каталог/service, замените /service/tinydns на путь к вашему пути инсталляции tinydns. Замените tinydns на dnscache, walldns и т.д. для других сервисов.
Пожалуйста, помните, что daemontools по настоящему очень полезен и вы оцените концепцию
/service самое большее через несколько дней, если поначалу откажитесь от запуска svscan вручную.
Как реализовать "split horizon" в tinydns?
"Split horizon" ("Расщепление горизонта") — это способ сделать так, чтобы один DNS-сервер отвечал на внутренние и внешние запросы, т.е. внутренние клиенты могли искать хосты в Интернет и внешние клиенты могли просматривать вашу DNS-зону.
Смысл в следующем:
Для "split horizon" обычно вы должны иметь два сетевых интерфейса на вашем хосте Пусть они будут называться eth0 и eth1. eth0 — внешний интерфейс с IP-адресом 204.71.200.33, eth1 — внутренний интерфейс с IP-адресом 10.1.2.3. Пусть имя вашего домена будет yahoo.com.
Теперь, чтобы получить желанную функциональность, вам необходимо запустить две копии tinydns. Одна будет обслуживать доступную всем версию вашей зоны, поэтому, как нетрудно догадаться, вы будете использовать внешний IP-адрес 204.71.200.33 для неё.
# tinydns-conf tinydns dnslog /var/tinydns-public 204.71.200.33
Чтобы обеспечить кэширующий DNS resolver для вашей LAN, вы запустите копию dnscache на внутреннем IP-адресе 10.1.2.3.
# dnscache-conf dnscache dnslog /var/dnscache 10.1.2.3
dnscache будет отвечать на запросы только с адреса 127.0.0.1 по умолчанию, так что вам придется это исправить:
# touch /var/dnscache/root/ip/10
Это разрешит dnscache отвечать на запросы с IP-адресов 10.*.*.* . Так как этот сетевой интерфейс находится в вашей LAN, внешние клиенты не смогут посылать запросы на него (если у вас есть firewall и вы настроили его кошерно).
Вторая копия tinydns будет обслуживать внутреннюю версию вашей зоны для LAN, и, т.к. оба IP-адреса уже заняты, вы настроите его на использование IP-адреса loopback-интерфейса 127.0.0.1.
# tinydns-conf tinydns dnslog /var/tinydns-private 127.0.0.1
Теперь, вы должны настроить ваш dnscache так, чтобы он посылал запросы к локальному tinydns когда он хочет сделать запрос к внутренней версии зоны yahoo.com. Это довольно легко:
# echo 127.0.0.1 > /var/dnscache/root/servers/yahoo.com # echo 127.0.0.1 > /var/dnscache/root/servers/10.in-addr.arpa
Вторая команда позволяет перенаправить обратные запросы (reverse lookups) вашему внутреннему tinydns.
Пожалуйста, помните, что лучше не делать "split horizon" на одной машине
из соображений безопасности, потому что злоумышленник, который проник на ваш DNS-сервер
может получить доступ к LAN через eth1. Лучшим решением является конфигурирование
tinydns на укрепленном хосте (bastion host) в сети перед firewall и запуск связки
dnscache/tinydns на другом хосте в LAN.
[Benett Todd прислал это описание методики "split horizon"
в mailing list. Вам оно может показаться более понятным для понимания.]
Как реализовать "split horizon", если есть только один сетевой интерфейс?
Из соображений безопасности вы не должны использовать "split horizon" только
с одним сетевым интерфейсом. Если вы все же хотите это сделать, вам необходимо
запустить второй сетевой интерфейс, который называется "dummy interface" или "alias
interface", в зависимости от терминологии вашей операционной системы. За подробностями
обращайтесь к документации вашей ОС. После этого просто используйте ту же конфигурацию,
как было описано выше.
Как мне сказать dnscache принимать запросы из 10.2.3.64-127 (CIDR)?
Просто перейдите в /service/dnscache/root/ip и создайте 10.2.3.64, 10.2.3.65, и т.д. Вы можете безболезненно сделать это с помощью скрипта, похожего на следующий (предполагается Bourne shell)
cd /service/dnscache/root/ip
touch 10.2.3.64
for i in `awk 'BEGIN { for( i=65; i<=127; i++ ) print i }'`; do
ln 10.2.3.64 10.2.3.$i
done
Использование ln взамен touch для всех файлов сохраняет inodes. Спасибо
Mate Wierdl за отправку этого замечания в mailing list.
Как мне переконвертировать файл зоны BIND в формат tinydns?
Разрешите зонную пересылку в BIND и используйте axfr-get из пакета djbdns чтобы скопировать данные в формат tinydns.
Затем используйте скрипт Todd'а Bennett'а, в частности, tinydns-data-compactor и tinydns-data-beautify, чтобы немного почистить данные (в tinydns несколько строк из файла зоны BIND могут быть записаны в одну строку — прим. перев.). [локальная копия]
Если вы планируете делать это регулярно, вы можете установить axfr-get локально на машине с BIND и использовать rsync-over-ssh чтобы копировать отконвертированные зоны на вторичный DNS-сервер с tinydns. Это весьма значительно увеличит безопасность и производительность.
Спасибо Raul Miller за этот ответ!
Как мне сказать вторичным DNS-серверам под управлением BIND обновлять свои зоны?
На tinydns.org есть perl-скрипт http://tinydns.org/dnsnotify чтобы посылать NOTIFY DNS-пакеты. [локальная копия]
tinydns записывает NOTIFY-запросы в лог примерно так:
HexSourceIP:HexSourcePort:QID I 0006 domain.xyНастройте свой log/run на отбор этих строк (multilog может это) и действуйте сответственно. Или взгляните на этот perl-скрипт, отправленный кем-то однажды в mailing list, который является оболочкой для multilog.
BIND 9 не принимает AXFR'ы от djbdns!
Greg Hewgill отправил патч для djbdns-1.04 в mailing list. Я слышал, что команда BIND исправила это в последних версиях BIND 9 (это был, конечно же, баг BIND'а).
Существуют несколько неофициальных сборок из нескольких источников (обычно, ссылки на них есть на tinydns.org). Тем не менее, запуск сервера имен — работа для опытных системных администраторов.
Самостоятельная сборка djbdns ничего сложного собой не представляет. Если вы считаете, что это для вас слишком сложно, пожалуйста, подумайте еще раз, действительно ли вы хотите быть администратором DNS-сервера. Некорректно настроенный сервер имен может доставить много неприятностей большому числу людей.
Tinydns совсем не отвечает, если кто-то ошибочно делегировал ему зону?
Да. Вы можете добавить эту строку в ваш data-файл для симуляции поведения BIND:
&::a.root-servers.net(Судя по всему, здесь имеется в виду случай, когда tinydns делегируется зона, для которой он в действительности не полномочен (отсутствуют записи в data). Tinydns в таких случаях просто игнорирует запрос, BIND обычно выдает список корневых серверов. — прим. перев.)
Во-первых, это не файл зоны. Файл data содержит все ваши записи, и неявно — зоны.
Во-вторых, это только так кажется. При первом взгляде на зонные файлы BIND многие люди также испытывают отвращение.
Эта таблица может помочь вам при чтении файла data:
| Это | создает это |
|---|---|
| . | SOA, NS, A |
| & | NS, A |
| @ | MX, A |
| = | PTR, A |
| + | A |
| ' | TXT |
| ^ | PTR |
| C | CNAME |
| Z | SOA |
| % | (условное выражение, описывающее расположение клиента, не создает какой-либо записи) |
| # | (комментарий, не создает какой-либо записи) |
| - | (используется для временного отключения A-записи, не создает какой-либо записи) |
| : | Определяется пользователем |
| 6 | AAAA, PTR (вместе с моим патчем) |
| 3 | AAAA (вместе с моим патчем) |
Но также почитайте
http://cr.yp.to/djbdns/frombind.html!
Смотрите также