Пропустити 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 не був би ймовірним вузьким місцем.