djbdns vs bind

Раньше я работал с djbdns, а сейчас использую несколько серверов BIND.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пропустить djbdns. Хотя djb - герой, он переносит высокомерие математика на программное обеспечение. Тот факт, что он не ведет себя как другое программное обеспечение в отношении запуска / остановки, может быть хорошей демонстрацией умной техники управления демонами. Но вам придется вытащить документацию, если вы не используете ее регулярно, потому что все совсем по-другому. Если вы настраиваете его в системах, которые также обслуживаются другими, вам нужно будет написать им четкую документацию, которую им нужно будет прочитать полностью, чтобы выполнять простые операции. Запускать что-то из init - это мило, даже умно. Но это также неприятно, удивительно и нестандартно.

Кроме того, у меня были проблемы с djbdns, вызывающие серьезные проблемы из-за того, что я настаивал только на соблюдении стандартов, а не на совместимости программного обеспечения. Устранение этих проблем было большой тратой времени, поскольку зависело от незначительных различий в пакетах DNS.

Кроме того, djbdns в некоторых случаях ведет себя странно, что может привести к тому, что люди будут устранять неполадки вашего DNS-сервера с помощью инструментов, отличных от djb (например, с помощью nslookup), чтобы получить удивительные результаты. Вы будете тратить свое время на объяснение: «На самом деле, я просто использую этот непонятный DNS-сервер под названием djbdns. Проблема в том, что ваши диагностические инструменты выдают вам странное сообщение, но оно работает нормально. Если вы посмотрите на этот захват пакета, вы можете сказать . Это не связано с проблемой, которая возникла у нас несколько месяцев назад, когда djbdns некорректно взаимодействовал с вашим DNS-сервером. Это также не связано с проблемой, которая возникла у нас несколько недель назад, когда меня не было в офисе, и это заняло мои товарищам по команде час, чтобы перезапустить DNS-сервер ".

Подобные проблемы с qmail повсюду.

В настройке djbdns есть некоторая образовательная ценность, если вы задаете вопрос и у вас есть время убить. Вы также можете многому научиться, просто прочитав сайт djb.

Есть два набора проблем безопасности. Дыры в безопасности, которые позволяют злоумышленнику получить доступ к системе - у djbdns почти наверняка их нет. Несколько лет назад bind за короткое время обнаружил довольно много неприятных, а также выявил плохой дизайн. Я ожидал, что за эти годы он был полностью переписан. Если вы действительно хотите быть в безопасности в этом отношении, запустите его на виртуальной машине (например, Xen). Также учтите, что если вы работаете в системе Linux с SELinux в целевом режиме, у вас будет настройка для привязки, и вы, вероятно, не будете беспокоиться о ней для 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 для справки, но переход на что-то другое сделает вас более счастливым системным администратором в будущем :)

Большинство мест, где я работал в индустрии интернет-провайдеров, похоже, используют 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, которые являются «произвольными» DNS-серверами уровня 3 и кажутся довольно быстрыми и надежными.

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

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