- RU.LINUX (2:5077/15.22) ------------------------------------------ RU.LINUX -
From : Alexei Kichkine 2:5020/400 15 Feb 01 08:55:40
Subj : djbdns
-------------------------------------------------------------------------------
From: Alexei Kichkine <ax@infocentr.ru>
Olli Artemjev <Olli.Artemjev@f1354.n5020.z2.fidonet.org> writes:
> Мне немного надоел BIND с его вечными багами и необходимостью его
> апгрейдить. Соответственно поглядел я на анонс dns'а от преподобного и в
> общем-то он мне понравился - 99% того что он не ломаем и апгрейдить его не
> придется еще долго. Однако есть у меня память работы с qmail и я помню, что
> без кучи патчей и приблуд он удобен только в редких случаях и к тому же не
> поддерживает кое-какие фичи, которые мне в общем то не очень нужны были, ну
> и как водится имеет некоторые глюки исключительно из-за мировоззрения
> ди-джея. Соответственно вопросы:
Патчей вроде особенно интересных и нет для djbdns. У меня так работает, без
них...
> 1) Hасколько удобен будет djbdns не в мелком офисе с одним доменом, а на
> провайдере с дестками или сотнями доменов.
Достаточно удобен. Поддерживает load-balancing, держит базу в cdb файле,
при изменении данных не требует перезагрузки/паузы/. Если ошибешься где-нибудь
в формате, когда исправлял данные - автоматически используется старый набор
данных.
Однако формат данных - полностью другой. Для случая с "десятками и сотнями
доменов" переписывание конфигов может вылиться в живопырку. Для перехода
с bind на djbdns есть FAQ на http://www.djbdns.org и даже вспомогательные
скрипты (там же), но как показывает практика - чтобы использовать
преимущества djbdns - все равно приходится "доводить напильником" полученные
конфиги.
Hасчет скорострельности - вроде все в порядке:
... site reported receiving 500 queries per second per server at peak times
for data from a 350-megabyte data.cdb. The tinydns process handled about 7000
queries per second of CPU time. The CPU was a Pentium III-550.
> 2) Hасколько он совместим с named'ом ( все-таки у большинства named):
> a) в плане трансфера зон и slave'ам на bind'е от master'а на djbdns, и
> наоборот поддержки slave'ов с мастером на bind'е.
В принципе djb потив zone-transfer методами bind. Он говорит, что сейчас
есть более зашишенные методы ( например scp или rsync ).
У меня сейчас оно работает с помощью rsync через ssh. Hо для тех кто не может
отказаться от bind на соседних серверах - предлагается использовать утилиты
из djbdns -
axfr-get - чтобы забрать описание зон с master сервера (и сохранить в формате
djbdns)
axfrdns - демон чтобы отдавать зоны в формате .
отдельная программулька на перле, чтобы посылать NOTIFY заинтересованным
серверам (лежит на http://www.djbdns.org )
Как _принимать_ NOTIFY с bind-серверов честно говоря не разбирался, т.к.
мне это не нужно.
> б) в плане поддержки исключительно-биндовских протоколов (насколько они
> кстати критичны в плане потери функциональности)?
приведи пример, а то я не понял, что ты имеешь в виду.
> 3) Какие вообще впечатления у общественности?
Переход c bind на djbdns стоил мне нескольких новых седых волос.. Hо в
принципе
ничего сверхьестественного там нет. Понятино, что как и qmail этот продукт
будет вызывать резкую аллергию у части населения.
Лично мне нравится. У него есть несколько фич, которые мне по душе.
Hапример - можно (с ограничениями конечно) использовать regular expression
в описании данных.
Типа говоришь что
*.some.host.ru имеет адрес 195.161.195.200
и тогда на запросы www.some.host.ru и ftp.some.host.ru и тд будет ответ
195.161.195.200
> 4) Какие идеологические засады на этот раз ввел дядя Бернштейн? (имеется
> ввиду что нить аналогичное неприятию в некоторых случаях вторичного MX'а
> qmail'ом.)
Диверсии/фичи:
1) Для работы djbdns требуется бернстайновский же daemontools. Hе все готовы
так сразу перейти с inetd/xinetd на svscan/tcpserver
2) djbdns _требует_ разделения днс-кэша и днс сервера. То есть _на_ _разных_
_IP_ запукаешь программу dnscache, которая снабжает днс-информацией "своих"
и программу, скажем tinydns, которая отвечает о твоих доменах всему остальному
интернету. В принципе в этом есть здравый смысл, но к примеру, мне пришлось
править свои записи в ripn.net чтобы обеспечить такое разделение.
3) djbdns "as is" любит UDP запросы и не любит TCP. Для того, чтобы он отвечал
на TCP запросы нужно дополнительный модуль ставить.
4)В djbdns есть возможность не прописыват многи вещи и djbdns сам следит за
ними
(типа номер SOA). Hо значения по умолчанию, которые он использует надо знать.
Hапример - надо знать, что если не припишешь e-mail ответственного лица,
будет использоваться hostmaster@твой.домен
> 5) Как водится у диджея его новое поделие модулизировано, и это
> хорошо. Однако есть ли тут скрытые неудобства?
> 6) Кто нить решился поставить это поделие в боевых условиях? И как успехи?
У меня работает в боевых условиях примерно месяца 3. Пока успешно, дальше
посмотрим..
--
Alexei Kichkine
--- ifmail v.2.15dev5 * Origin: Infocentr.ru (2:5020/400)
