djbdns vs bind [закрито]


20

Я новачок, який хоче навчитися встановлювати сервер імен DNS. Чи варто використовувати djbdns, BIND чи щось інше?

Поточні вимоги до мережі включають підтримку субдоменів, SSL та поштову службу, і це дуже незначний трафік. Мені б хотілося рішення, яке колись може збільшити масштабний трафік і, можливо, складніші вимоги (наприклад, балансування навантаження). У цей час я працював або на Linux.

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

Спасибі.


Авторитетний сервіс чи рекурсивний?
bortzmeyer

Авторитетний, я думаю.
черневик

Відповіді:


14

У минулому я працював з djbdns і зараз запускаю купу серверів BIND.

Найбільша проблема з djbdns найкраще ставити так, як мій вчитель першого класу помістив її на мою картку звіту: "не грає добре з іншими". Він просто не поводиться як інше на коробці Unix всілякими дуже маленькими способами, які можуть вас кусати пізніше. Він використовує синтаксис для зонних файлів, яких ви більше не побачите.

Найбільшою перевагою djbdns є те, що він був розроблений з нуля з безпекою як мета №1.

Якщо ви збиралися налаштувати DNS-сервер, відкрийте його в Інтернеті, а потім ніколи його не підтримуйте, djbdns - це шлях.

У реальному світі більшість адміністраторів краще використовувати пакети BIND від постачальника ОС та оперативно виправляти їх, коли є оновлення. Але запустити його в хронічному режимі - це гарна ідея, і зберігати авторитетні DNS-сервери окремо від рекурсивних DNS-серверів-рекурсивних - хороша ідея.

Якщо ви знайдете документи для чогось із DNS, BIND буде включений, а djbdns навряд чи буде включений. Якщо ви використовуєте dig, формат, який він повертає, можна вставити у файл зони BIND і працювати. Він діє як будь-який звичайний демон Unix, а не щось з іншої планети.

Ми використовуємо деякі апаратні балансири навантаження та балансуємо навантаження на наших рекурсивних розв’язувальних BIND-серверах; працює чудово. Просто переконайтеся, що користувачі отримують той самий вихідний IP-адресу, коли вони надсилали свої запити, і будь-яка установка балансування навантаження UDP та TCP повинна працювати. Якщо ви працюєте з авторитетним DNS, балансування завантаження настільки ж просто, як наявність декількох серверів і публікація їх у Whois info; інші DNS-сервери розумно завантажуватимуть баланс.


2
Мені подобається думати про це так, ніби djdns не працює, це ви, якщо це так, то його ді-джеї.
Дейв Чейні

2
Вся дискусія корисна, і виділення будь-якої однієї відповіді здається трохи несправедливим для інших. Цей варіант найближчий до висновку, який я дійшов для себе: незалежно від їх технологічних відмінностей, BIND краще підтримується документацією та спільнотою. Як зазначається ще одна відповідь, розуміння, мабуть, спростить майбутні взаємодії DNS. Ці переваги здаються важливішими за будь-яку вигоду, яку пропонує djbdns у простоті конфігурації.
chernevik

9

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

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

Обидва невеликі (тому, ймовірно, мають менше дірок у безпеці, які чекають їх виявлення), активно підтримуються та підтримують усі останні DNS-речі (DNSSEC, IPv6 тощо).

Інакше BIND - це хороше програмне забезпечення.

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


8

Якщо це для вас самих, і якщо ви хочете дізнатися, як працює DNS, я б використовував djbdns.

Якщо ви хочете зрозуміти, як усі інші роблять DNS, і як підтримувати типові розгортання для підприємств, навчіться зв'язувати.

Якщо ваша мета - мінімальні зусилля та підтримка, і ви досить компетентні, djbdns має набагато нижчу підтримку.

Якщо ви більше ставитеся до початківця сторони огорожі, вам, мабуть, буде легше перев’язатись і бігти, але майте на увазі, що набагато більше шансів вибухнути дивними і хитрими способами.

Якби я ще не знав djbdns (і прив'язував), я також би заглянув у powerdns та maradns, але сумніваюся, що для крихітних установок це краще, ніж пакет djbdns.

Незважаючи на те, навіть якщо ви використовуєте прив'язку для реклами свого DNS в Інтернеті, вам все одно слід запустити dnscache (частина пакета djbdns), що працює на localhost для вирішувача вашої системи.


6

Пропустити djbdns. Хоча djb - герой, він переносить зарозумілість математика до програмного забезпечення. Той факт, що він не веде себе як інше програмне забезпечення щодо запуску / зупинки, може бути хорошою демонстрацією розумної техніки управління демонами. Але вам доведеться витягнути документацію, якщо ви не використовуєте її регулярно, адже все так інакше. Якщо ви налаштовуєте його на системи, які підтримують і інші, вам потрібно буде написати їм чітку документацію - яку їм потрібно буде прочитати в повному обсязі для виконання простих операцій. Виконувати речі з ініту мило, навіть розумно. Але це також неприємно, дивно і нестандартно.

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

Також djbdns має певну поведінку у певних випадках, яка спричинить проблеми людей із сервером DNS за допомогою інших інструментів, ніж djb (наприклад, з nslookup), щоб отримати дивовижні результати. Ви витратите свій час на пояснення "насправді, я просто використовую цей незрозумілий DNS-сервер під назвою djbdns. Проблема полягає в тому, що ваші діагностичні інструменти дають вам дивне повідомлення, але воно працює нормально. Якщо ви подивитеся на це захоплення пакетів, ви можете сказати Це не пов'язано з тією проблемою, яку ми мали кілька місяців тому, коли djbdns не працював належним чином з вашим DNS-сервером, а також не з тією проблемою, яку ми мали кілька тижнів тому, коли я був поза офісом, і це взяло мою товаришів по команді годину, щоб перезапустити DNS-сервер. "

Подібні проблеми з qmail у всьому світі.

У налаштуванні djbdns є якась освітня цінність, якщо ви ставите питання і маєте час на вбивство. Ви також можете багато чого навчитися, просто прочитавши веб-сайт djb.

Існує два набори питань безпеки. Дірки в безпеці, які дозволяють зловмиснику отримати доступ до системи - djbdns майже точно не має жодного з них. Деякі роки тому у бінда було виявлено досить багато незручних, виявлених за короткий час, які також виявили поганий дизайн. Я б очікував, що за ці багато років він буде повністю переписаний. Якщо ви дійсно хочете бути безпечними в цьому відношенні, запустіть його під віртуальною машиною (наприклад, Xen). Також врахуйте, якщо ви працюєте в системі Linux із SELinux в цільовому режимі, у вас буде налаштування для прив’язки і, ймовірно, не буде турбуватися з одним для djbdns. Система bind + SELinux потенційно є більш захищеною.

Інше питання - безпека від отруєння кешами. Я здогадуюсь, що djbdns був кращим, коли він був випущений, а зв'язування, мабуть, краще зараз завдяки більшій увазі. Це, мабуть, причина Вашого слуху, що зв'язування є небезпечним, якщо "правильно налаштовано". Вам слід хоча б дослідити та зрозуміти це питання. У процесі ви, ймовірно, дізнаєтесь, які існують ризики конфігурації для обох серверів DNS.

Поведінка під великим навантаженням є критерієм дурниць для більшості користувачів. Остерігайтеся продуктивності, яка використовується як критерій оцінки програмного забезпечення, яке рідко є вузьким місцем. Ви не розміщуєте кеш-сервер DNS для величезної бази користувачів, де ви можете отримувати запити зі значною швидкістю. Ви використовуєте авторитетний DNS для надання послуг, які, ймовірно, працюють в одній системі. Ці послуги в тисячі разів дорожчі, ніж DNS. Вашого інтернет-посилання може бути недостатньо навіть для великого завантаження вашого DNS-сервера, але якби ви отримували таке велике навантаження на надані вами послуги, DNS не був би ймовірним вузьким місцем.


5

Ви можете ознайомитись з MaraDNS , DNS-сервером, захищеним від безпеки.

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

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

  • Простий у використанні. Основна рекурсивна конфігурація потребує лише одного конфігураційного трипорядкового файлу. Основна авторитетна конфігурація потребує лише чотирирядкового файлу конфігурації та однорядного файлу зони. MaraDNS повністю задокументований, як з простими підручниками, так і з повним та сучасним довідковим посібником.

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

  • Відкрите джерело. MaraDNS є повністю відкритим кодом, Ліцензія - це двокласна ліцензія BSD, яка майже ідентична ліцензії FreeBSD.

Дивіться сторінку адвокатури maraDNS, де є порівняння декількох програм DNS-сервера, які можуть допомогти вам вибрати.


MaraDNS більше не підтримується автором, як зазначається на головній сторінці проекту: maradns.org
Джозеф

1
Як виправлення, хоча MaraDNS більше не розвиваю, я все ще підтримую його (виправлення помилок, оновлення нових компіляторів та дистрибутивів Linux тощо). Насправді я лише випустив новий реліз MaraDNS цього року (2014) і, мабуть, зробить наступний рік: maradns.samiam.org/download.html
samam

4

Якщо ви використовуєте DNS лише для себе, djbdns - кращий програмний пакет. Це був один з небагатьох програмних пакетів, який виявив головну проблему безпеки DNS минулого року і був розроблений / виправлений, щоб виправити це за роки до цього. Для кешування DNS я встановлюю dnscache (частина djbdns) на всі сервери, які не працюють як авторитетні DNS-сервери. Це дійсно працює краще, ніж BIND для більшості предметів, але, враховуючи сучасне обладнання, зайва вага та менша швидкість BIND - це не проблема.

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

Djbdns налаштований таким чином, щоб його легко було адмініструвати з командного рядка. Усі зміни даних DNS виконуються як команди. У BIND ви редагуєте серію текстових файлів.

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


3

Особисто я б сказав, що вам потрібно вивчити основи BIND для довідок, але перехід на щось інше зробить вас щасливішим системним адміністратором на майбутнє :)

Більшість місць, де я працював у галузі провайдерів, здається, використовують djbdns, він надає чудові будівельні блоки та основи для шару "керованих" служб зверху - написання сценаріїв для створення зонних файлів досить тривіально, тобто ви можете зберігати всі свої дані DNS в SQL все одно. Він обробляє смішну кількість запитів в секунду і захищений під час завантаження.

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

Інші речі, про які варто прочитати, - це MaraDNS та PowerDNS.


2

Я в основному використовую FreeBSD для подібних речей, і оскільки він постачається в комплекті з BIND, я ніколи насправді не брав зусиль, щоб дізнатися щось інше. Хоча я вважаю BIND досить простим у налаштуванні, і оскільки він підтримується FreeBSD в перспективі безпеки, мені потрібно лише відстежувати цей канал для будь-яких проблем із безпекою.

Тож я гадаю, що найкраще для вас спробувати обидва і побачити, який із них вам найбільше підходить, тобто якщо ви не використовуєте ОС, яка постачається в комплекті з будь-якою з них.


2

Якщо ви хочете дізнатися про DNS, копія книги O'Reilly " DNS і BIND " та встановлена ​​остання версія прив’язки - це, мабуть, найкращий шлях.

Це правда, що у BIND протягом життя виникало більше проблем із безпекою. до минулого року dnjdns не мав жодної, але вона має зовсім іншу архітектуру від BIND, і вам може бути складніше підібрати, якщо ви не знайомі з тим, як працює система імен.

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

Як і будь-яка послуга, що стосується Інтернету, найкращим способом є здоровий глузд і прагматичне мислення, незалежно від того, яке програмне забезпечення ви використовуєте. Якщо вам потрібно ввімкнути динамічні оновлення, переконайтеся, що вони підписані. Якщо ви дозволите передачу зон, обмежте, хто може їх виконувати з вашого суворого і т.д.


1
Я спілкувався з djbdns, швидко потрапляв на деякі незначні проблеми з установкою, і виявив, що просто не дуже велика громада документує такі проблеми. Для цього немає нічого подібного до "DNS та BIND". Навіть якщо я пройду цю перешкоду, все, що я хотів би зробити, швидше за все, обговорюватиме рішення BIND. Будь то технологія краща чи ні, BIND, схоже, має кращу підтримку.
черневик

Мабуть, не так важко, як хотілося б. Я намагаюся робити роботу і робити найкращий вибір, який я можу, за обмеженого розуміння, а не вичерпати потенціал будь-якого конкретного інструменту. Я вдячний за djbdns, perl, lighttpd, Free BSD та всі інші речі з відкритим кодом, якими я зараз не користуюся. Ну, майже всі. Але я не думаю, що ти можеш серйозніше очікувати на новичка RTFM чи шукати TFM більше, ніж я. Ви чітко інвестуєте в djbdns, і це чудово. Якщо моя думка вас дратує, я думаю, ви можете сподіватися на розумніших новачків, або можете працювати над тим, щоб нам було легше знайти відповіді.
chernevik

2

СПІЛЬНИЙ.

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

До речі, приємно читати джерело BIND і дізнаватися, як, наприклад, працюють класичні функції, такі як gethostbyname () або gethostbyaddr ().


2

Після років використання bind, нарешті, мені зрозуміло, що більшості моїх серверів взагалі не потрібно запускати свій власний демон DNS. Це може не стосуватися вас, але подумайте: практично кожен реєстратор домену в цей час пропонує сервер ваших DNS-записів для вас (як правило, дає вам якийсь веб-спосіб редагування своїх записів DNS). Вони обробляють подачу інформації, керування вторинними документами тощо. Якщо ви видалите потребу вашого сервера відповідати на запити DNS, все, що залишилося, - це ваш сервер робити пошук DNS. Для цього я вказую свої /etc/resolv.conf на 4.2.2.1 та 4.2.2.2, які є серверами DNS Level3 "anycast" і здаються досить швидкими та надійними.

Додатковим бонусом є те, що конфігурація брандмауера для вашого сервера більше не повинна пускати в DNS. Вам просто потрібно "встановлене, пов'язане" правило, щоб дозволити роботу DNS-запитів вашого сервера.

Гаразд, тому ви не запитували, чи потрібно запускати демон DNS, але це питання, на яке я відповів. Щоб бути повноцінним, якщо ви виявите, що ви повинні запустити його, я рекомендую дотримуватися прив’язки, тому що це так часто використовується, ви знайдете багато документації та допоможете зробити так, щоб ви хотіли.


Здається розумним, але здається, простіше зрозуміти, як це працює, спочатку влаштовуючи його сам.
chernevik
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.