[zandreich]

Народ кто чего скажет, стала делема я за djbdns (просто, понятно, без дырок и стабильно) другой человек уперся в bind и ничего слушать не хочет. кто чего скажет BIND или DJBDNS

от DNS требуется только кэширующий и primary зона

[Dm1try]

BIND - потому что DJDNS морально устаревшая и необновляемая поделка.

[photon]

BIND - потому что DJDNS морально устаревшая и необновляемая поделка.

Ну и в чем же он "морально устарел" по сравнению с bind? Djbdns, между прочим, оказался не подвержен той нашумевшей уязвимости, которую опубликовал Dan Kaminsky. Если зона большая, то лучше сделать мастер зоны на PowerDNS, чтобы хранить информацию в SQL-базе. Если это не провайдерский DNS, а всего лишь мастер зоны и кэш для небольшой конторы, то выбор того или иного демона из соображений безопасности и стабильности не принципиален, т.к. всерьез ломать вас никто не будет. Нужно использовать то, что заведомо проще администрировать, т.е. bind.

Изменено 7 мая, 2009 пользователем photon

[zandreich]

BIND - потому что DJDNS морально устаревшая и необновляемая поделка.

Ну и в чем же он "морально устарел" по сравнению с bind? Djbdns, между прочим, оказался не подвержен той нашумевшей уязвимости, которую опубликовал Dan Kaminsky. Если зона большая, то лучше сделать мастер зоны на PowerDNS, чтобы хранить информацию в SQL-базе. Если это не провайдерский DNS, а всего лишь мастер зоны и кэш для небольшой конторы, то выбор того или иного демона из соображений безопасности и стабильности не принципиален, т.к. всерьез ломать вас никто не будет. Нужно использовать то, что заведомо проще администрировать, т.е. bind.

а если зона большая? и нужна стабильность и безопасность? что тогда на мой взгляд лучше djbdns от др. Берштейна пока ничего не придумано, да конечно я согласен что есть определенный нестандартный подход к некоторым вещам но все же DJBDNS рулит к томуже поддерживает postgresql http://tinydns.org

 

BIND - потому что DJDNS морально устаревшая и необновляемая поделка.

а что там обновлять если не найдено еще ни одной уязвимости, в отличии от бинда по который все время выпускают новые версии и патчи закрывающие дырки

[photon]

а если зона большая? и нужна стабильность и безопасность? что тогда на мой взгляд лучше djbdns от др. Берштейна пока ничего не придумано, да конечно я согласен что есть определенный нестандартный подход к некоторым вещам но все же DJBDNS рулит к томуже поддерживает postgresql http://tinydns.org

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

[sirmax]

Я когда-то делал тест скорости ДНСов...

http://wiki.sirmax.noname.com.ua/index.php....80.D0.BE.D0.B2

[photon]

Подобные тесты не имеют никакого смысла, если не указаны конфигурационные файлы всех исследуемых серверов. Первое, что нужно было сделать -- поставить везде одинаковые размеры кэша и снять ограничения на число запросов в секунду. Отставание tinydns при увеличении размеров зоны можно объяснить ограничениями на размер кэша в RAM. Если обнаружится, что тормоза связаны с используемым в tinydns алгоритмом поиска, то PowerDNS нужно юзать и на рекурсорах.

Изменено 9 мая, 2009 пользователем photon

[sirmax]

Подобные тесты не имеют никакого смысла, если не указаны конфигурационные файлы всех исследуемых серверов. Первое, что нужно было сделать -- поставить везде одинаковые размеры кэша и снять ограничения на число запросов в секунду. Отставание tinydns при увеличении размеров зоны можно объяснить ограничениями на размер кэша в RAM. Если обнаружится, что тормоза связаны с используемым в tinydns алгоритмом поиска, то PowerDNS нужно юзать и на рекурсорах.

Я cейчас уже не найду наверно конфиги, но можем проделать повторный тест во вторник-среду, если хотите....

 

[photon]

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

[zandreich]

любопытно увидеть норомальный тест

Изменено 12 мая, 2009 пользователем zandreich

[sirmax]

photon

у Вас есть опыт работы с tinydns?

у меня - не получалось совсем, хотя вроде там настроек совсем не много...

 

Завтра займусь, наверно, тем более что даво самому пора переходить на PowerDNS

[zandreich]

photon

у Вас есть опыт работы с tinydns?

у меня - не получалось совсем, хотя вроде там настроек совсем не много...

 

Завтра займусь, наверно, тем более что даво самому пора переходить на PowerDNS

вообще с tinydns все очень просто

[dvolodin]

Народ кто чего скажет, стала делема я за djbdns (просто, понятно, без дырок и стабильно) другой человек уперся в bind и ничего слушать не хочет. кто чего скажет BIND или DJBDNS

от DNS требуется только кэширующий и primary зона

Как всегда, правильный ответ зависит от нераскрытых в вопросе деталей. Пока нет данных по количеству запросов к авторитетным серверам и кешам, на каком железе все крутится, что есть сейчас и какая инфраструктура для поддержки DNS уже развернута весь вопрос сводится к: "коллега любит яблоки, а я не признаю ничего кроме баклажанов". Лучший инструмент тот, которым вы умеете пользоваться.

 

Вообще нужны ОЧЕНЬ веские основания, чтобы НЕ ИСПОЛЬЗОВАТЬ bind (не хватает каких-то позарез нужных фич, не хватает производительности, bind не вписывается в имеющуюся инфраструктуру). В вашем случае таких оснований пока не видно.

 

Мы несколько лет вполне успешно использовали связку из bind'ов и NOC'а для DNS provisioning'а. Есть-пить не просило, зоны рулятся из web-интерфейса, реверсные зоны строятся автоматом, апдейты зон разносятся на нужные сервера, конфиги самих bind'ов не трогались месяцами.

[Просто интересуюсь]

Не знаю как у вас, господа, а у меня в компании все dns-сервисы (размещение доменов, dns-кеш, обратные зоны и т.п.) всё полностью сделано на djbdns. Доменов (точнее зон) в сумме обслуживается 16185, записей в зонах в сумме 29513. Нарисовать трансляцию из веб-морды в конфиг djbdns никакой сложности не представляет.

 

Вообще нужны ОЧЕНЬ веские основания, чтобы НЕ ИСПОЛЬЗОВАТЬ bind (не хватает каких-то позарез нужных фич, не хватает производительности, bind не вписывается в имеющуюся инфраструктуру). В вашем случае таких оснований пока не видно.

Вообще-то оснований более чем достаточно:

1. Периодически находимые дыры, тянущие за собой необходимость апгрейдов

2. Совмещение в одном демоне всех функций, таких как dns-кеш для клиентов и размещение зон. В итоге домен протух или переехал, а в вашей сети он продолжает работать как будто ничего не произошло, но только в вашей сети и больше нигде.

[st_re]

2. разнесите по разным демонам. в независимости от названия програмного продукта.

[zandreich]

2. разнесите по разным демонам. в независимости от названия програмного продукта.

а зачем что то придумывать если уже все придумано берштейном

[dvolodin]

Вообще нужны ОЧЕНЬ веские основания, чтобы НЕ ИСПОЛЬЗОВАТЬ bind (не хватает каких-то позарез нужных фич, не хватает производительности, bind не вписывается в имеющуюся инфраструктуру). В вашем случае таких оснований пока не видно.

Вообще-то оснований более чем достаточно:

1. Периодически находимые дыры, тянущие за собой необходимость апгрейдов

5 штук за последние 7 лет, если мне не изменяет память. Причем, большая часть в функционале, который не реализован в djbdns и вряд ли когда нибудь будет реализован.

 

2. Совмещение в одном демоне всех функций, таких как dns-кеш для клиентов и размещение зон. В итоге домен протух или переехал, а в вашей сети он продолжает работать как будто ничего не произошло, но только в вашей сети и больше нигде.

Так кто же заставляет так делать? Держите отдельные bind'ы как авторитетные сервера и запретите выполнять им рекурсивные запросы, а для клиентов заведите рекурсивные серверы, которые обрабатывают только рекурсивные запросы.

[dvolodin]

2. разнесите по разным демонам. в независимости от названия програмного продукта.

а зачем что то придумывать если уже все придумано берштейном

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

Кстати, а что именно придумано Бернштейном для распределения нагрузки по ядрам?

Не менее интересно, каким образом в djbdns реализуются view.

И какие вообще механизмы придуманы Бернштейном для реализации балансировки нагрузки (особенно интересен развод клиентов по датацентрам в зависимости от местонахождения клиентов и загрузки серверов/каналов).