Пропустить djbdns. Хотя djb герой, он переносит высокомерие математика на программное обеспечение. Тот факт, что он не ведет себя как другое программное обеспечение в отношении запуска / остановки, может быть хорошей демонстрацией умной техники управления демонами. Но вам придется вытащить документацию, если вы не используете ее на регулярной основе, потому что все так по-другому. Если вы установите его в системах, которые также поддерживают другие, вам нужно будет написать им ясную документацию, которую они должны будут прочитать полностью для выполнения простых операций. Запускать вещи из init - это мило, даже умно. Но это также неприятно, удивительно и нестандартно.
Кроме того, у меня были проблемы с djbdns, вызывающие серьезные проблемы из-за необходимости соблюдения только стандартов, а не из-за совместимости программного обеспечения. Устранение этих проблем было большой тратой времени, поскольку зависело от незначительных различий в пакетах DNS.
Кроме того, в некоторых случаях djbdns ведет себя странно, что приводит к тому, что люди устраняют неполадки на вашем DNS-сервере с помощью инструментов, отличных от djb (например, с помощью nslookup), чтобы получить удивительные результаты. Вы будете тратить свое время на объяснения «на самом деле, я просто использую этот неясный DNS-сервер под названием djbdns. Проблема в том, что ваши диагностические инструменты выдают вам странное сообщение, но он работает хорошо. Если вы посмотрите на этот захват пакета, вы можете сказать, Это не связано с проблемой, которая была у нас несколько месяцев назад, когда djbdns неправильно взаимодействовал с вашим DNS-сервером. Также это не связано с проблемой, которая возникла у нас несколько недель назад, когда меня не было в офисе, и это заняло у меня товарищи по команде час, чтобы перезапустить DNS-сервер. "
Схожие проблемы с qmail.
Настройка djbdns имеет определенную образовательную ценность, если вы задаете вопрос и у вас есть время убить. Вы также можете многому научиться, просто читая сайт djb.
Есть два набора проблем безопасности. Дыры безопасности, которые позволяют злоумышленнику получить доступ к системе - у djbdns почти наверняка нет ничего из этого. Несколько лет назад у bind было довольно много смущающих, обнаруженных за короткое время, что также выявляло плохой дизайн. Я ожидаю, что за эти годы он был полностью переписан. Если вы действительно хотите быть в безопасности в этом отношении, запустите его под виртуальной машиной (например, Xen). Также учтите, что если вы работаете в системе Linux с SELinux в целевом режиме, у вас есть настройка для bind, и, вероятно, вам не понадобится настройка для djbdns. Система bind + SELinux потенциально более безопасна.
Другая проблема - безопасность от отравления кэша. Я предполагаю, что djbdns был лучше, когда он был выпущен, и bind, вероятно, теперь лучше благодаря большему вниманию. Вероятно, это причина того, что вы слышите, что привязка небезопасна, если она не «правильно настроена». Вы должны хотя бы исследовать и понять эту проблему. В процессе вы, вероятно, узнаете, какие риски конфигурации существуют для обоих DNS-серверов.
Поведение под большой нагрузкой является бессмысленным критерием для большинства пользователей. Остерегайтесь производительности, используемой в качестве критерия для оценки программного обеспечения, которое редко является узким местом производительности. Вы не размещаете сервер кэширования DNS для огромной пользовательской базы, где вы можете получать запросы со значительной скоростью. Вы используете авторитетный DNS для предоставления услуг, которые, вероятно, работают в той же системе. Эти услуги в тысячи раз дороже, чем DNS. Ваша интернет-связь может быть недостаточной даже для интенсивной загрузки вашего DNS-сервера, но если вы получаете такую большую нагрузку на предоставляемые вами услуги, DNS вряд ли станет узким местом.