Статья в КомпьютерПрайс про сервер dnsmasq

Хорошая штука, рекомендую.

для маленьких локалок, для которых BIND слишком тяжелый -- в самый раз ;)

>для маленьких локалок, для которых BIND слишком тяжелый

в плане? можно подумать, он может нагрузить сильно сервер _маленькой_ локалки :)

Нет, прикол в том, что его не надо настраивать (ну по крайней мере так как bind) -- это ж просто бальзам :) А насчет маленьких локалок -- в статье написано почему.

Настраивать его попроще. И не такой дырявый, как BIND.

Настройка BIND это целая песня :(

по поводу самой тулзы ничего не скажу, но попробую. если это действительно нормальная альтернатива (как dovecot вместо монстров cyrus или courier), которой таки-можно пользоваться - будет у меня жить :)

а статья какая-то странная. цитата оттуда:

> Но есть и ещё одна причина. BIND разрабатывается и распространяется под открытой лицензией. В этих условиях единственным источником дохода становится техническая поддержка. Техподдержка со стороны разработчика нужна преимущественно в момент установки очередной версии ПО. Протокол DNS давно оформился и существенным изменениям более не подвергается. Следовательно, поводом к появлению новых версий остаётся только исправление ошибок. Поэтому разработчикам становится выгодно исправлять ошибки постепенно, чтобы заставить потребителей устанавливать всё новые и новые версии, и при этом запутывать код, чтобы затруднить другим программистам создание конкурентных проектов на его базе.

Вот мне и интересно, что они курили?

ничего не курили, диджея начитались...

DHCP (Dynamic Host Configuration Protocol, протокол динамической настройки компьютеров)

Это супер, DHCP теперь только компы конфигурит,
это не курить надо, а просто редактор класный =))))

А так, тулза может и полезная, но надо посмотреть, кто юзать будет =)
что скажут, по натуре я консерватор =)
просто так, все снести и поставить, это экстрим
Ядро у меня даже дома 2.4

> Настройка BIND это целая песня :(

Один раз спел и нет больше страха перед выходом на сцену. Другое дело, что BIND действительно прожорлив.

Ничего они не курили. Это элементарные основы существования в капиталистическом обществе.

Не понял из статьи, как он может зону отдавать наружу? В частности, откуда ему знать, кто у меня mx? Из этого я делаю заключение, что он только как кэширующий может работать.

> Более предпочтительным представляется не поручать dnsmasq эту задачу вообще, а воспользоваться услугами провайдера или бесплатного публичного DNS-сервиса наподобие www.xname.org.

Более предпочтительным представляется поставить djbdns и не парить себе мозг. Особенно если речь идет о мелкой сетке, в которой нет специального админа: поставил djbdns и забыл о нем.

> В частности, для его [djbdns] запуска требуются два вспомогательных пакета, написанных самим Бернстайном: daemontools для запуска системных сервисов и ucspi-tcp для запуска сетевых сервисов.

ucspi-tcp нужен только для axfr. Кстати dnsmasq вообще не поддерживает axfr (если верить твоей же статье). Хотя ему, собственно, и не надо, если он только кэширующий.

> Хотя это и не вызывает особых проблем, сама непривычность конфигурирования [djbdns] и необходимость администрировать ещё одну систему управления сервисами в дополнение к стандартной являются недостатками.

Ну конечно,

echo значение >/дира/файл

это настолько непривычный метод конфигурирования, что потребует длительного спец.обучения.

А вся "необходимость администрировать" состоит в одноразовом (после установки djbdns) выполнении команды

svscanboot &; echo 'svscanboot &' >>/скрипт/инициализации/системы

Ну просто ужасные недостатки. :)

Разумеется, еще остается необходимость выкачать daemontools. Тоже ведь существенный минус -- аж 31К нужно скачать (ucspi-tcp -- 45К тарбол).

А еще в твоей статье есть несколько забавностей, не относящихся к dns. Вот например такая:

> основные настройки (как правило, расположенные в файле /etc/ИмяСервиса.conf или каталоге /etc/ИмяСервиса) рекомендуется без веских оснований не трогать

Почему? А вот потому что

> с файлом, который не изменялся после установки, не возникает проблем при автоматизированном обновлении программы до следующей версии.

Я чуть со стула не упал. :) Хорошая у тебя получилась реклама для Alt-linux. :)

> Ничего они не курили. Это элементарные основы существования в капиталистическом обществе.

Ну давайте еще К.Маркса сюда приплетем. На самом деле все просто: писатели BIND не знают про UNIX way или не хотят придерживаться его принципов. "Одна задача -- одна программа". У них куча задач повешена на одну программу (как в виндах). Из-за этого программа тяжелая и глючная. У DJB все по науке: куча мелких программ, на каждый чих отдельная. Оттого и качество выше.

Ещё один поклонник диджея...

В каком месте он прожорлив, извините? Факты в студию! Море зон на одной машине, куча поддоменов, 3-й, 4-й, 5-й уровень, все кешируется. Простая банка пень-200MMX. Что-то не замечал великой загрузки.

И ещё интересно узнать, чем так сложен bind?

BIND не проц, память жрет. У меня BIND9 - 29592k в памяти. Для примера: одна копия апача - 14716k squid - (12960+1344+2236+4136)k 30 метров оперативки для современных машин, конечно не проблема :) , но - здесь немножко, там немножко - уже глядишь свопится...

"Dnsmasq is distributed under the GPL". для некоторых этого достаточно, чтобы его (Dnsmasq) не использовать. а вот BIND и DHCPD напротив - выпускаются ISC под лицензией, эквивалентной BSD. разницу, я думаю, объяснять нет необходимости.

к тому же, я как-то не заметил особых "трудностей в настройке и тормозов" у BIND и DHCPD.

О, лучше не привыкать. Потом и простое покажется очень сложным.
Прога очень спорная по полезности. А что касается серверов dhcp, то
их далеко не один экземпляр, как указано в статье. Очень неплох udhcpd.
Для djbdns тоже есть решение - dhcp_dns: http://www.thismetalsky.org/magic/projects/dhcp_dns.html

у меня dnsmasq - VIRT/RSS/SHARED 212/172/172 kb

а бинд жрал много :(

> У DJB все по науке: куча мелких программ, на каждый чих отдельная. Оттого и качество выше.

А при чём тут диджей? Он к dnsmasq не имеет отношения, у него для dns другая совсем софтина - tinydns + dnscache. Тоже на любителя.

> Другое дело, что BIND действительно прожорлив.

Ага. Глянул. Сервер маленькой локалки - несколько десятков компов.
BIND сожрал аж 3068 kB! Во как! Офигеть как много!

Ндя... сча глянул, BIND много памяти скушал - 50 метров....

Нос другой стороны, на этом серваке кроме DNS ничего не крутится :)

> Нос другой стороны, на этом серваке кроме DNS ничего не крутится :)

Надо полагать это сервер НЕ_МАЛЕНЬКОЙ локалки? :-)

> В частности, откуда ему знать, кто у меня mx?

В dnsmasq.conf поищи буковки "mx". Их есть там.

Да хотя бы вот этим:
$TTL 1D
$ORIGIN ru.
rxvt IN SOA websrv.rxvt.ru. root.websrv.rxvt.ru. ( ...
Что, покороче или почитабельнее было не сделать?
Разве эту дурь возможно правильно с нуля написать, не имея перед глазами образца (каковым для меня лично много лет назад стал редхатовский caching-nameserver)? А необходимость почти всегда писать одно и то же в прямой и реверсивной зоне? А изврат с реверсивными зонами для сетей классов A и B?

Писать одно и тоже в прямые и обратные зоны нужно не всегда. Иногда очень даже разное. Кроме того, кто сказал, что файлы зон должны редактироваться вручную? У кого как, а у нас они из базы генерятся. Ну а уж какой ты к базе прикрутишь фронтенд, это от фантазии зависит. BIND хорош своей хорошей задокументированностью, строгим соответствием RFC (Чего не скажешь, скажем о Microsoft DNS Server). Ну а Бернстайн известный шизик. Чего стоил баг с MXами в qmail. Его проекты я лично (сугубо IMHO) игнорирую. Если бы он платил деньги не за дыры в безопасности, а за простые баги - давно разорился бы.

Особенно нравится сентенция про "Протокол DNS давно оформился и существенным изменениям более не подвергается". Что значит давно? Давно ли у нас есть инкрементальный трансфер зон и трансфер по запросу, защищенные соединения и прочее? Учтите, что все это входит в стандарт протокола DNS. Насколько эти вещи поддерживаются dnsmasq-ом?

ага. а сели бы байнд бы платил за дыры в безопасности - давно бы по миру пошел

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

100?
500?
1000?

> Чего стоил баг с MXами в qmail.
это не баг. а фича.
раньше (когда компы ьыли большими) - MX не было.

> для некоторых этого достаточно, чтобы его (Dnsmasq) не использовать
а мне - наоброт плюс. что он не повторит судьбу gated как, возможно, в ближайшем будущем bind.

> пень-200MMX. Что-то не замечал великой загрузки.
а вот припрётся к вам тот червяк что великую нагрузку на DNS создаёт - узнаешь где раком зимуют.:-)

Ну вот как раз и новость про очередное обновление дырявого бинда подоспела...

Вот статистика бинда с загрузков в 2500 доменов второго уровня (вторичный):
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
312 named 11 0 1860 1860 1360 S 1.9 0.3 0:00 named

Вот статистика бинда с загрузкой в ~ 100 доменов (второго и третьего уровня), первичный:
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
3538 named 15 0 7348 5440 3804 S 0.1 1.0 0:07 0 named

вторичный:
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
3541 named 15 0 6288 4400 3804 S 0.1 0.8 0:04 0 named

Ну, если уж top-ами меряться, вот тебе tinydns, который отдает 21612
уникальных записей, создавая 30-40 Gb исходящих ответов в месяц.

PID USERNAME PRI NICE  SIZE    RES STATE    TIME   WCPU    CPU COMMAND
231 tinydns    2   0  1012K   284K sbwait   0:10  0.00%  0.00% tinydns


А вот покажи мне цифры кеширующего named, на который ходит, скажем,
10000 клиентов?

> который отдает 21612 уникальных записей

Пардон, большинство из них -- '=', т.е. одновременно A и PTR, соответственно для named это будет больше 40000 записей. Плюс каждое описание SOA превратится в последнем в три.