/me проблем с bind'ом не имел так как юзает djbdns =)

А почему ты его пользуешь? Убеди!

1) секьюрно. "Поставил и забыл" (с)
2) полная модульность. я юзаю совершенно отдельно в разных местах local cache, external cache, dns server.
3) ГОРАЗДО ПРОЩЕ и БЫСТРЕЕ в настройке и понимании.

Насчет настройки и понимания уж точно! :)

1) У Вас он нормально с intel.com RR забирает?
2) а задачи отдать свою зону secondary на BIND не бывает?
3) Иногда необходимо совместить cache+master/slave zone - для djbdns необходим отдельный IP для каждой службы.
4) Не умеет по определённым условиям отдавать разные IP для одной и то же RR (полезно для multi-home).

2 mumpster (*) (2002-05-21 12:37:54.575) Это все о чем? Кое что, кажется имеет отношение к обоим...

одним словом - djbdnsrules двумя djbdns rules :)

у него есть свои "недостатки" не может он быть на одном ip и кэшируещим и основным, например, но тогда можно говорить и о недостатках философии юникс, которая явно не приветствует "кучи дерьма в упаковке", чем является вышеуказанный продукт (?) BIND...

На счет невозможности выполнения нескольких функция сразу на одном ip - в принципе в нормальных ситуациях dnscache+tinydns+axfrdns (для них же :)) - это вполне рабочая схема. На остальные не жалко выделить отдельный ip.

Короче, если надо чтобы сервисы были неубиваемые - ставьте djbdns, если охота геморой иметь (слава тебе господи, прошла болезнь, вылечили мою задницу :)) - можно поиграться с остальной байдой.

Извиняюсь за свое нападенческое поведение, ну не смог удержать себя! Серъезно...

как насчёт моих вопросов 1, 2 и 4?
или djb уже научился любить domain/tcp и RR более 511 байт?
я вполне серьёзно спрашиваю, поскольку рецепта не знаю.

BIND и DHCP нормально работают:!? Может не врубаюсь я в некоторые тонкости здешней беседу, но всё номано: как кэширующий, и как обычный, для своей зоны... В чём с ними могут быть проблемы?...
Если насчёт djbdns - то просто не знаю даже, что это такое :) Если традиционные, достаточно хорошо описанные и распространённые вещи работают, то в чём проблема-то? Да и в распространённости плюс - больше пользователей - быстрее буги вылавливаются :)...
Трудностей в настройке, акромя своего начального нежелания читать :), не заметил... Как и тормозов или ресурсоёмкости в работе... :)

Да уж. Если почитать внимательно, то все понятно становится. (это по поводу BIND) Что я с успехом и сделал в свое время, тем более, что "доки" на эту тему вполне достаточно.

А насчет того, что "падает" и т.д. Так, пожалуйста, не голословно выражайтесь. У меня проблем нет ни с тем, ни с другим сервисом, которые, кстати, по DDNS увязаны.

> 4) Не умеет по определённым условиям отдавать разные IP для одной и то же RR

Умеет. И намного удобнее в нем это настраивается. RTFM.

Предлагаю закрыть тему в пользу DJBDNS :)

безопасность==(квалификация+исправления)/функциональность

=> безопасность можно улучшить
либо повышением квалификации програмистов(трудный путь)
либо исправлением багов(длинный путь)
либо уменьшением возможностей.

AFAIK DJB выбрал последний.
Его страницы об djbxxx vs bind оставляют такое впечатление:
"Этого и этого и этого и... мы не умеем, ну и на@#$@#$ не нужно".
В некоторых случаях это приемлемо. А мне, например, нравятся
views и DNS updates.

Да уж! Без DNS updates как-то скучно :)

сексу мало?;-)
AFAIK не имевшие dynamic zones и имевшие ddns-update-style none, deny unknown-clients могли спать спокойно при последней дырке в DHCP.

BTW, пусть знающие как сделать Multi-home RR в djb поделятся конкретно ссылкой на дкоцию.

Иметь проблемы можно от кучи приятных вещей(не только от BINDа). Но не лучше ли слегка рисковать и получать удовольствие?

> BTW, пусть знающие как сделать Multi-home RR в djb поделятся конкретно ссылкой на дкоцию.
http://cr.yp.to/djbdns/faq/tinydns.html#differentiation

> => безопасность можно улучшить
> либо повышением квалификации програмистов(трудный путь)
> либо исправлением багов(длинный путь)
> либо уменьшением возможностей.
>
> AFAIK DJB выбрал последний.

Не угадал. Он является одним из лучших специалистов в области сетевой безопасности.
Он так же является очень грамотным С-программером. Так что ИМХО первый пункт.
Все остальное - простота, надежность, безопасность его софта - следствие его высокой квалификации.

И так на вопросы от mumpster (*) (2002-05-21 12:37:54.575)
Начнем с того что я точно знаю.
2) Бывает. Для этого существает такая утилита в djbdns как axfrdns.
3) Отдельный IP необходим не для каждой службы. На один IP вместе не ставятся только external cache и dns server.
Только у меня сразу вопрос а зачем вам надо и кеш и днс вместе особенно с учетом того что у вас не хватает IP? Если какая-нибудь сеть с ходит наружу через маскарад например то кеш ставится на внутренний ip а dns на внешний.
4)
Q: How do I balance load among my web servers? I have 50 identical servers running on IP addresses 1.2.3.150, 1.2.3.151, and so on. I'd like to spread www.heaven.af.mil requests among those servers.

A: Simply put all 50 addresses into data. tinydns will automatically return a random set of 8 addresses for each request.

Оно?
http://cr.yp.to/djbdns/faq/tinydns.html#config

1) А кто такой RR и в чем должна быть проблема с intel.com можно поподробней?

Насчет квалификации, исправлений и функциональности. Мало кто может похвастаться квалификацией как у DB. Насчет исправлений, это вас багливый софт (sendmail, BIND and Co) приучил что все время лезут баги и дырки которые от версии к версии фиксятся. В продуктах DB нет багов и как следствие нет исравлений. А насчет функциональности вот мы щас помойму разберемся что djbdns делате все чего не хватало например mumpster'у. IMHO то что не умеет djbdns и умеет BIND может понадобиться только провайдерам или очень крупным компаниям с кучей сетей, ip, хостов которые имеют централизованое упраление всем этим хозяйством.

Господа :), позвольте пофилосовствовать ....
Итак, прога есть - которая типа, лучше традиционной. Написал её кадр :), чьи познания в этой областе даже и не будем подвергать сомнениям... И есть программа старая, толстая... :) Тащится она давно... (писать её начали динозавры, наверное... :)
Итак... Первое... Топик не про первую :)
Второе... Допустим, она предоставляет уйму возможностей, но немного пока "недотягивает", ну "самую чуть"... Но гораздо надёжнее и "прочнее"......
Итак, стоит ли мне переползать на новую? НЕ ЗНАЮ... Просто надо смотреть с точки зрения того, как где и кто?
Если я админ "толстой" сети - то наверное, выберу первую... Почему? Поддержка лучше (всётаки много народу колупается :)), привычнее, всё обкатано, да и известно
Если я начинающий: тоже старую - доки больше, людей с ней знакомых больше... и.т.п.
Если же у меня средняя сеточка, уже достаточно знаний и.т.п. - я могу и начать разбираться в новинке...
Однако всегда остаётся вопрос: а что если девелопер... бросит или что ещё стрясётся?... Хотя исходники открыты: но бровзить чужой текст не в кайф :) Да и долго, если рабочей доки нет...
Я не агитирую "за советскую власть" :) Просто, как грит безвременно слинявший Авел :) - "так карта легла" :)
Как курьёз ... Студент один, написал за неделю свой ДНС... Работает, даже вроде дыр нет :)

А можно я тоже пофилософствую?
Если уже стоит и работает BIND. То переходить ли на новую уже дело админа. Но если ставить заново то все приведеные выше аргументы не соответсвуют истине.
Подвергать сомнениям познания DB в С программинге и безопасности дейтвительно не будем.
Если ты админ толстой сети... А какая разница насколько толстая сеть? Дело не в том большая или малая сеть. Дело в том если ли в твоей сети динамические изменения хостов по отношению к ip и тп специфических вещей. У тебя есть?
Какую поддержку представляет BIND по отношению к djbdns я обсолютно не вижу. Обкатаность? Дык мы и видим что BIND обкатывают, сколько там было дырок и багов? Доки? Доки по бинду огромны и запутаны даже и сравнения никакого с доками по djbdns. Новичку это серьезный chalange изучить доки по BINDу.
Девелопер ты чего? Девелоперов делающих BIND единицы на масштаб инета.

> Обновить свое ПО - дело полезное.

Неверно, когда дело касается софта от djb.
Я бы вывел такое правило: Обновить свое ПО - дело абсолютно необходимое,
если это ПО от Paul Vixie, Eric Allman или в названии фигурирует слово "Berkeley" ;)
Это не пустые слова, а грустная статистика...

> 3) Отдельный IP необходим не для каждой службы. На один IP вместе не ставятся только external cache и dns server.

Большая беда?

tinydns на 127.0.0.1
dnscache на 192.168.100.1

Работает однако.

Единственное чего мне не нравиться в DJB так это то что для tynydns все зоны надо описывать в одном файле который затем конвертиться в бинарный формат. А так все замечательно.

> Студент один, написал за неделю свой ДНС... Работает, даже вроде дыр нет :)
хотя бы 500 рублей даёт за обнаружение дыр?;-)

> Только у меня сразу вопрос а зачем вам надо и кеш и днс вместе особенно с учетом того > что у вас не хватает IP? Если какая-нибудь сеть с ходит наружу через маскарад
> например то кеш ставится на внутренний ip а dns на внешний.
IP у нас хватает - 10/8,192.168/16,172.16/12.:)
просто не хочется зря alias вешать. но мне уже подсказали про tinydns на 127.0.0.1.
просто удобно всё совмещать на одной машинке.
осталось понять как аналог forward делать.
> How do I balance...
мимо кассы - мой случай - "diffirentiate" там же в FAQе. BTW, в BIND предалагется это делать уродскими views.
> А кто такой RR и в чем должна быть проблема с intel.com можно поподробней?
1) RR - resource record (см. соотв. RFCs), т.е. A, PTR, NS, etc.
2) см:
dig intel.com. in mx|wc
39 168 1218
~>dig intel.com.|wc
24 91 604
~>dig intel.com.in ns|wc
18 75 507
~>dig www.intel.com.|wc
25 96 675

доступно?
раньше у djbdns были проблемы с такими зонами (в udp-то они не влазят).
> Насчет квалификации, исправлений и функциональности
речь не только по это, а то что он...гхм...своеобразный человек - сначала бинарники с
конфигами в /var сложил, затем пытался логи в /etc писать, теперь вот всем
предлагает в /service складывать то что должно по идее либо в /etc либо в /var лежать.
А вообще, не знаю как djbdns но вот qmail у него точно к работе непригоден без исправлений.
> может понадобиться только провайдерам или очень крупным компаниям с кучей сетей,
> ip, хостов которые имеют централизованое упраление всем этим хозяйством.
а вот почти как про меня.:-)

To: anonymous (*) (2002-05-22 06:18:29.325) Есть толи патч тольи модуль (я этом не занимался) который позволяет хранить зоны в SQL есть и для того чтоб их хранить в разных файлах. Вобщем это не проблема.

> осталось понять как аналог forward делать.

1. echo "1" > /service/dnscachex/env/FORWARDONLY 2. echo "x.x.x.x" > /service/dnscachex/root/servers/@ echo "y.y.y.y" >> /service/dnscachex/root/servers/@

> А вообще, не знаю как djbdns но вот qmail у него точно к работе непригоден без исправлений.

Без исправлений вообще ничего не пригодно к работе. Даже сам линукс, то бишь ядро. В случае с qmail мне пришлось применить всего один патч, чтобы он понимал переменную окружения QMAILQUEUE, для сканирования всей проходящей почты.

> осталось понять как аналог forward делать.

1. echo "1" > /service/dnscachex/env/FORWARDONLY
2. echo "x.x.x.x" > /service/dnscachex/root/servers/@
echo "y.y.y.y" >> /service/dnscachex/root/servers/@

> А вообще, не знаю как djbdns но вот qmail у него точно к работе непригоден без исправлений.

Без исправлений вообще ничего не пригодно к работе. Даже сам линукс, то бишь ядро. В случае с qmail мне пришлось применить всего один патч, чтобы он понимал переменную окружения QMAILQUEUE, для сканирования всей проходящей почты.

А как там у djbdns обстоит дела с IPv6? кто-нибудь использует это в жизне? просто у бинда с этим все на высшем уровне уже года 2-3... а кто-нибудь тестировал djbdns под нагрузкой скажем в 4-5 милионов запросов в сутки? для сервера с 128мб, на котором еще крутится и мыло(на 1-2 сотни доменов) и ньюсы это нормально...

Осталось провести голосование на тему BIND vs DJB.
Правда количество здесь не показатель :) - не все что много есть хорошо.
Однако с чего это все взяли, что в DJB нет "глюков". Они есть везде. Только, если пользователей меньше -обнаружить их сложнее. А абсолютно безглючными могут быть только проги типа "Hello, world", на asm'е писаные.
Однако, DJB я обязательно попробую :)

Уважаемые, а где этот самый djbdns лежит?

Скачал DJBDNS и нифига не смог его запустить на Linux. Понятно, что он требует какие-то неродные для Linux пакеты, причем устаревшие. Так на хрен он нужен, если проблема в BIND только написать файл конфигурации, а в DJBDNS проблема запусить его.

Не понимаю, откуда такие слова про сложность bind ?

Мне тоже недавно пришлось ставить DNS сервер. Я как белый человек решил посмотреть на этот djbdns скачал, облазил весь сайт. Доки не структурированы, все разбросано как попало, запустить с ходу не получается ну и о каком удобстве вы говорите?

Теперь bind - скачал 9 версию, залез на сайт нашел ОДНУ! обратите внимание, одну небольшую pdfку, в которой все было описано. Я ее прочитал и настроил все как мне хотелось и представьте себе работает!

Никому из тех кто решил настраивать DNS не советую изучать что то кроме bind. Вот когда станете толстопузыми самодовольными админами, наченете мучаться от безделья, вот тогда Берштейн да пребудет с вами :)

> 1. echo "1" > /service/dnscachex/env/FORWARDONLY
это forward only, а forward first?
> Без исправлений вообще ничего не пригодно к работе. Даже сам линукс, то бишь ядро. В
не знаю - крайне редко ядро на серверах пачим.
> случае с qmail мне пришлось применить всего один патч, чтобы он понимал переменную
> окружения QMAILQUEUE, для сканирования всей проходящей почты.
счастливый - у нас накладывается более 20.

> Он является одним из лучших специалистов в области сетевой безопасности.

Он является самым лучшим пускателем пыли в глаза.

> Он так же является очень грамотным С-программером.

Ха-ха-ха.

PS С bind9 нет никаких проблем. А вот 8 действительно дыряв как решето.

Насчёт студенческого сервера DNS
:) Ктоб ему самому дал 5р на булочку :) А тут за дыркотестёрство с него стрясти 500 пытаетесь :)... Его, кстати, просили настроить DNS - а он написал... :) Грит, что не понял ... :D:D:D:D поставленной задачи...

Насчёт Берштейновского размещения: если бы я был немецкоязычным: то с "ходу" бы так и считал, что etc (e.t.c. прочее, и так далее ) - для всякого хлама :):):). Наверное и все остальные выкрутасы из этого...
Исходники dj... весьма непросто читаемы.... А путеводителя, как в DNS/BIND нет... Если подумать, то действительно возможно любой продукт переписать заново "начисто", без выкрутасов... И не учитывая спецфичных возможностей, ну или не совсем их учитывая... :)

Если уж голосовать: то мой выбор DNS|BIND ... Причины я много раз излагал выше... Ещё одна причина: это если кому понадобится "поправить" чего без меня: то скорее спец по ним найдётся, нежели по dj... Если уж совсем приспичит, то и переписать участки можно...

> просили настроить DNS - а он написал
дык я и говорю - он готов бабки отстегнуть как DJB за своё"творчество"?
> так и считал, что etc (e.t.c. прочее, и так далее ) - для всякого хлама
вообще-то etc - это просто сокращение от латинского выражения et cetera ("и т так далее"). jfyi.

> Исходники dj... весьма непросто читаемы.... А путеводителя, как в DNS/BIND нет
типа по исходникам named уже написан путеводитель.;-)
исходники djb нормально читаемы как таковые но комментарии там встречаются крайне редко
уже из-за одного этого я не соглашусь что он отличный C-программер

не знаю - мой опыт "голосования" убедил меня в том, что единственная большая проблема qmail перед sendmail - непроходимое упрямство djb.
в исходном виде qmail совершенно непригоден (как я уже говорил) к массовой установке
из RPM "out-of-box". Но работы ведутся:) - если кому интересно, сообщите, мы можем
выложить a-la "sendmail killer".
вот присматриваюсь к djbdns.
BTW, кто-нибудь слышал про альернативные DHCP под UNIX (не ISC)?
А тот вот надо было сделать WPAD нормальный - а не вышло...:-(
> если кому понадобится "поправить" чего без меня: то скорее спец по ним найдётся
знаете, таких "спецов" по BIN/DHCP, которые и по sendmail "спцеы" - куча, но что про PrivacyOptions ничего не слышали, что про deny unknown-client &>/dev/null
как говорится "простота хуже воровства"
уж лучше пусть со сложным qmail/djbdns разбираются, у которых те же самые функции сделаны, но гораздо проще - поэтому докция на порядок менее объёмная.
чем больше смотрю на BIND - тем всё большее он раздражение вызывает.
тут кто-то говорил что типа BIND9 "белый и пушистый" - идите на багтрах, посчитайте сколько уже раз он там побывал. то же про dhcp.
Эй, кто-нибудь знает альтернативу для dhcp?
особо интересно чтобы на уровне dhcpv3 - с 2-3 dhcpd в одной сети (failover)

2PitStop
"Однако с чего это все взяли, что в DJB нет "глюков". Они есть везде. Только, если пользователей меньше -обнаружить их сложнее."
Бред. А нет глюков у него потому что не найдено за годы работы ни одного. А у бинда достаточно почитать bugtrack и changelog.

Кто там не смог запусть djbdns - прочти инструкцию еще раз. djbdns не требует вообще никаких дополнительных системных пакетов и либ.

А кто там усердно патчит qmail, мозно узнать зачем? У меня вот работает прекрасно outofbox.

2 anonymous (*) (2002-05-22 17:16:07.488)
> А нет глюков у него потому что не найдено за годы работы ни одного. А у бинда достаточно почитать bugtrack и changelog.

А кто эти глюки искал? Сколько юзающих оное ПО? У меня BIND/DHCP не глючит и что с того? Ошибки-то в нем есть! Но у меня нет нескольких тысяч клиентов и не обрабатывается по миллиону запросов в сутки. А у кого DJB на такой нагрузке пашет? (вопрос был задан выше)

Отсутствие "bugtrack и changelog" не говорит об отсутсвии ошибок, не так ли? Я программировал гораздо более простые вещи, а ошибки, пусть и не критичные, все равно выползали! (об этом тоже писалось выше) Так что все это фигня!
Чем длиннее changelog, тем активней работают ребята :) (шутка)

> кто там усердно патчит qmail, мозно узнать зачем? У меня вот работает прекрасно
> outofbox
ну если у тебя он один и тебя не мучает спам, устраивает бинари, лежащие в /var, и т.д. - флаг в руки.

я просто не знаю Ваших критериев "прекрасной работы". Для меня это - в том числе беспроблемная установка на несколько машин и с нужными мне настройками (включая приём почты только для явно разрешённых мною пользователей - одной этой штучки достаточно
чтобы sendmail иногда лучше qmail).

для любителей BIND:
BTW, все в курсе про http://www.linux-mag.com/2001-03/bind_01.html ?
IMHo полезно, особенно если про GC & GSS-TSIg впервые слышишь.:-)

Тесты о производительности djbdns есть на сайте про него. Где-то там DB писал об этом.
А юзает его очень много людей. Это не та прога про которую никто не слыхал. Даже тут во флейме виндо что куча людей знакома с творениями DB. А уж как дыры в этих продуктах ищут это вообще хит уже которого сезона. Там даже премия в 500$ есть кто найдет. До сих пор не нашли.
Ты просто не сталкивался но продукты DB всегда вспоминаются на тему "софт без дырок".

А насчет того что продукты DB не ставятся из RPM это не из-за того что они не приспособлены для этого а просто из-за запрета лицензии.

У меня бывает. Только это _bind_, а не djbdns. Редко, но бывает. А в среднем - чуть-чуть не переползает милиона запрсов в сутки. Максимальное было несколько милионов( 4-5 ), но это в результате нештатной ситуации. Я когда на утро статистку глянул, чуть сам не офигел. Так что запас прочности у него порядочный... ЗЫ. так как там у djbdns с IPv6???? Про AAAA записи он хотя бы знает? Про А6 я уж и не зарекаюсь... Бернштейн наверно скажет что это ему нафиг не нужно, а значит остальным тоже не нужно 8-)

2mumpser
"Для меня это - в том числе беспроблемная установка на несколько машин и с нужными мне настройками (включая приём почты только для явно разрешённых мною пользователей - одной этой штучки достаточно
чтобы sendmail иногда лучше qmail)."

А просто в /dev/null писать почту для тех кого нет в системе и отправлять обратно уведомление что почта не принята не решит проблему?

"Куча людей" в этом флейме - не показатель количества пользователей этого DJB. Я хотел бы взглянуть хоть на какую-нибудь статистику! Кто там чего ищет я не знаю! И кому охота тратить уйму времени за $500?

Хотя, я не исключаю, что продукт сей, весьма надежен! :)

2anonymous (*) (2002-05-22 17:47:57.388)
А что кому-то действительно нужно А6 и AAAAA? Тебе что нужно? Где-то в интернете оно используется?
http://cr.yp.to/djbdns/killa6.html и я с ним согласен.

2anonymous (*) (2002-05-22 18:08:14.199) Ты будешь смеяться - да. За развитие IPv6 дают деньги. _Очень_ хорошие деньги. В том числе и российские конторы дают на это гранты. Хотя их масштаб конечно не сопоставим с буржуями. Но ведь лишние деньги не бывают 8-))) А вы пока напрягайтесь за 500баксов от "гуру" ...

2anonymous (*) (2002-05-22 18:08:14.199) В продолжении... И именно на этой неделе мое руководство укатило на очередную конференцию - "налаживать контакты", где демонстрируют сервер из нашей сети, у которого снаружи сервисы доступны _только_ по IPv6

>не знаю - мой опыт "голосования" убедил меня в том, что единственная большая проблема qmail перед sendmail - >непроходимое упрямство djb. >в исходном виде qmail совершенно непригоден (как я уже говорил) к массовой установке >из RPM "out-of-box". Но работы ведутся:) - если кому интересно, сообщите, мы можем >выложить a-la "sendmail killer".

мне интересно, выложи плиз :)

"где демонстрируют сервер из нашей сети, у которого снаружи сервисы доступны _только_ по IPv6"
А провайдер у вас IPv6 держит? А у тех кто коннектиться к нему будет пров IPv6 держит?