The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

djbdns


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
- 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)


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>

 Добавить комментарий
Имя:
E-Mail:
Заголовок:
Текст:




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2021 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру