djbdns против bind [закрыто]

Я новичок, который хочет узнать, как настроить DNS-сервер имен. Должен ли я использовать djbdns, BIND или что-то еще?

Текущие сетевые требования включают поддержку поддоменов, SSL и почтовый сервис, все при очень небольшом трафике. Мне бы хотелось решение, которое могло бы когда-нибудь масштабироваться до более интенсивного трафика и, возможно, более сложных требований (таких как балансировка нагрузки). В это время я бы работал на Linux.

Я читал, что у BIND есть проблемы с безопасностью, если он не настроен должным образом, и что его конфигурация может быть сложной. Я также читал, что djbdns проще в настройке, более безопасен и подходит для больших нагрузок. Аргументы в пользу djbdns кажутся правдоподобными, но у меня нет опыта, чтобы правильно их оценить. Если BIND лучше, я был бы признателен за обсуждение этих требований для djbdns.

Благодарю.

В прошлом я работал с djbdns и в настоящее время использую несколько серверов BIND.

Самая большая проблема с djbdns - это то, как мой учитель в первом классе написал это в моем табеле успеваемости: «плохо играет с другими» Он просто не ведет себя как что-либо еще на Unix-блоках всеми видами очень маленьких способов, которые могут укусить вас позже. Он использует синтаксис для файлов зон, которые вы больше нигде не увидите.

Наибольшим преимуществом djbdns является то, что он был спроектирован с нуля с целью обеспечения безопасности в качестве цели # 1.

Если вы собираетесь настроить DNS-сервер, выставить его в Интернет, а затем никогда не поддерживать, djbdns будет подходящим вариантом.

В реальном мире большинству администраторов лучше использовать пакеты BIND от поставщика ОС и быстро их исправлять при появлении обновлений. Но запускать его chroot - хорошая идея, и держать ваши авторитетные DNS-серверы отдельно от ваших DNS-серверов с рекурсивным распознавателем - хорошая идея.

Если вы найдете документы для чего-то с DNS, BIND будет включен, и djbdns вряд ли будет включен. Если вы используете dig, формат, который он возвращает, может быть вставлен в файл зоны BIND и работать. Он действует как любой обычный демон unix, а не как что-то с другой планеты.

Мы используем некоторые аппаратные балансировщики нагрузки и балансируем нагрузку на наших серверах BIND с рекурсивным распознавателем; работает отлично. Просто убедитесь, что пользователи получают тот же исходный IP-адрес, на который они отправляли свои запросы, и любая настройка балансировки нагрузки с поддержкой UDP и TCP должна работать. Если вы используете авторитетный DNS, балансировка нагрузки так же проста, как если бы вы имели несколько серверов и опубликовали их все в информации whois; другие DNS-серверы будут разумно распределять нагрузку.

Для авторитетного сервиса, nsd .

Для рекурсивного, несвязанного .

Оба они небольшие (поэтому, вероятно, имеют меньше дыр в безопасности, ожидающих своего обнаружения), активно поддерживаются и поддерживают все последние функции DNS (DNSSEC, IPv6 и т. Д.).

В противном случае BIND - хорошее программное обеспечение.

djbdns - это проект, состоящий из одного человека, долгое время не поддерживаемый, не более безопасный (автор просто так говорит), а официальный веб-сайт полон ошибок. (Теперь я уверен, что получу много отрицательных отзывов от djbboys, моя репутация была слишком высокой на мой вкус :-)

Если это для вас самих, и если вы хотите узнать, как работает DNS, я бы использовал djbdns.

Если вы хотите понять, как все остальные работают с DNS и как поддерживать типичные корпоративные развертывания, изучите bind.

Если ваша цель - минимальные усилия и поддержка, и вы достаточно компетентны, у djbdns намного меньше накладных расходов на поддержку.

Если вы находитесь на стороне новичка, вам, скорее всего, будет легче освоиться, но имейте в виду, что вероятность его взрыва необычным и дурацким способом гораздо выше.

Если бы я еще не знал djbdns (и bind), я бы также посмотрел на powerdns и maradns, но я сомневаюсь, что для крошечных установок это лучше, чем набор djbdns.

В любом случае, даже если вы используете bind для рекламы своего DNS в Интернете, вы все равно должны запустить dnscache (часть пакета djbdns), работающий на localhost для распознавателя вашей системы.

Пропустить 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 вряд ли станет узким местом.

Возможно, вы захотите взглянуть на MaraDNS , DNS-сервер с защитой.

• Закрепить. MaraDNS имеет историю безопасности так же хорошо, как и любой другой DNS-сервер. Например, MaraDNS всегда рандомизировал, используя безопасный генератор случайных чисел, идентификатор запроса и порт источника DNS-запросов; и никогда не был уязвим для «новой» атаки отравления кэша.

• Поддерживается. MaraDNS имеет долгую историю поддержки и обновления. Первоначально MaraDNS был создан в 2001 году. MaraDNS 1.0 был выпущен в 2002 году, а MaraDNS 1.2 был выпущен в декабре 2005 года. MaraDNS был тщательно протестирован как с использованием процесса SQA, так и более чем четырехлетним использованием в реальных условиях. MaraDNS продолжает полностью поддерживаться: последний выпуск был сделан 13 февраля 2009 года. Deadwood, код, который станет частью MaraDNS 2.0, активно разрабатывается.

• Легко использовать. Базовая рекурсивная конфигурация требует только одного файла конфигурации из трех строк. Для базовой официальной конфигурации требуется только файл конфигурации из четырех строк и файл зоны из одной строки. MaraDNS полностью документирован как с простыми учебными пособиями, так и с полным и актуальным справочным руководством.

• Маленький. MaraDNS хорошо подходит для встроенных приложений и других сред, где сервер должен использовать минимально возможное количество ресурсов. Двоичный файл MaraDNS меньше, чем у любого другого поддерживаемого в настоящее время рекурсивного DNS-сервера.

• Открытый источник. MaraDNS является полностью открытым исходным кодом. Лицензия представляет собой лицензию BSD с двумя разделами, практически идентичную лицензии FreeBSD.

См. Страницу поддержки maraDNS, где есть сравнение нескольких программ для DNS-серверов, которые могут помочь вам выбрать.

Если вы используете DNS только для себя, лучше использовать djbdns. Это был один из немногих пакетов программного обеспечения, который выявил серьезную проблему безопасности DNS с прошлого года и был собран / исправлен за несколько лет до этого. Для кеширования DNS я устанавливаю dnscache (часть djbdns) на все серверы, которые не работают как официальные DNS-серверы. Он действительно работает лучше, чем BIND для большинства элементов, но, учитывая современное оборудование, дополнительный вес и более медленная скорость BIND не проблема.

Для опыта я изучил бы основы BIND, независимо от того, какой пакет вы выбрали для запуска.

Djbdns настроен так, чтобы его было действительно легко администрировать из командной строки. Все изменения в данных DNS выполняются в виде команд. В BIND вы редактируете серию текстовых файлов.

Вы можете получить пакеты для обоих. Я рассматриваю разницу как IE по сравнению с другими браузерами. IE встроен и работает для многих вещей, и вы не можете изменить его по умолчанию. Djbdns отличается и требует другого набора компромиссов. Для интернет-провайдера переход от BIND к djbdns может быть немного сложнее, потому что BIND по умолчанию выполняет кэширование и обслуживание имен, где djbdns разделяет это на две части. Это предпочтительное решение безопасности, но сложнее в настройке, поэтому многие установки BIND не беспокоятся.

Лично я бы сказал, что для справки вам нужно изучить основы BIND, но переход на что-то другое сделает вас более счастливым системным администратором в будущем :)

В большинстве мест, где я работал в ISP-индустрии, похоже, используется djbdns, он предоставляет отличные строительные блоки и основы для создания слоя «управляемых» сервисов поверх - написание скриптов для генерации файлов зон довольно тривиально, то есть вы можете хранить все свои данные DNS в любом случае в SQL. Он обрабатывает смешное количество запросов в секунду и безопасен для загрузки.

Если вам нужно масштабировать его, просто зайдите на http://haproxy.1wt.eu и подключите несколько авторитетных серверов за этим! Я также настоятельно рекомендую отделить средства распознавания от надежных серверов в любой настройке, которую вы хотите развернуть.

Другие вещи, о которых стоит прочитать, это MaraDNS и PowerDNS.

Я в основном использую FreeBSD для такого рода вещей, и поскольку он поставляется вместе с BIND, я никогда не пытался чему-то научиться. Однако я нахожу BIND довольно простым в настройке, и, поскольку FreeBSD поддерживает его с точки зрения безопасности, мне нужно только отслеживать этот канал на наличие проблем с безопасностью.

Поэтому я думаю, что лучший выбор для вас - попробовать оба и посмотреть, какой из них подходит вам больше всего, если только вы не используете ОС, поставляемую в комплекте с любым из них.

Если вы хотите узнать больше о DNS, лучшим выбором будет копия книги О'Рейли « DNS и BIND » и последней установленной версии bind.

Это правда, что у BIND было больше проблем с безопасностью в течение жизни. У dnjdns не было ни одного до прошлого года, но у него совсем другая архитектура по сравнению с BIND, и вам может оказаться сложнее подобрать его, если вы не знакомы с тем, как работает система именования.

Если вы просто хотите узнать, как запустить DNS- сервер (в отличие от изучения протоколов и тому подобного), вам лучше всего выбрать один и погрузиться в него. Я полагаю, вы найдете двоичные пакеты для обоих в любом дистрибутиве * nix, который вы выберете. Тем не менее, есть некоторые преимущества для компиляции из исходного кода с программным обеспечением, которое вам может понадобиться пересобрать, если будет объявлено об уязвимости безопасности.

Как и в случае с любыми другими интернет-услугами, лучше всего придерживаться здравого смысла и прагматичного мышления, независимо от того, какое программное обеспечение вы используете. Если вам нужно включить динамические обновления, убедитесь, что они подписаны. Если вы разрешаете перенос зон, ограничьте, кто может выполнять их с вашего сервера и т. Д.

BIND.

Если вы научитесь настраивать его (читая целый ряд довольно утомительных RFC-документов, связанных с DNS), то в будущем вы можете легко переключиться на другой DNS-сервер (для любых целей). Я использую BIND в качестве основного и вторичного серверов везде на FreeBSD, Linux и даже на ноутбуке Vista (для хостов VMware NAT).

Кстати, довольно забавно читать исходные тексты BIND и узнавать, как, например, классические функции, такие как gethostbyname () или gethostbyaddr (), работают.

После многих лет использования bind я наконец понял, что большинству моих серверов вообще не нужно запускать свой собственный DNS-демон. Это может не относиться к вам, но подумайте об этом: в настоящее время практически каждый регистратор домена предлагает вам обслуживать ваши DNS-записи (обычно предоставляя вам какой-то сетевой способ редактирования ваших DNS-записей). Они обрабатывают информацию, управляют вторичными системами и т. Д. Если вы устраняете необходимость ответа сервера на запросы DNS, вам остается только выполнить поиск DNS вашим сервером. Для этого я указываю мои /etc/resolv.conf на 4.2.2.1 и 4.2.2.2, которые являются «anycast» DNS-серверами уровня 3 и кажутся довольно быстрыми и надежными.

Дополнительным бонусом является то, что конфигурация брандмауэра для вашего сервера больше не должна пропускать DNS. Вам просто нужно «установленное, связанное» правило, чтобы DNS-запросы вашего сервера работали.

Итак, вы не спросили, нужно ли вам запускать DNS-демон, но на этот вопрос я ответил. Просто чтобы завершить, если вы обнаружите, что должны запустить один, я рекомендую придерживаться bind, потому что он используется так часто, что вы найдете много документации и поможете заставить ее делать то, что вы хотите.