Новые версии BIND и DHCP

А вообще-то у djbdns очень четкий API и сделать патч для AAAA не сложно. И патч этот есть, правда написаный не самим DB.
А A6 и DNAME broken by desing.

to mumpster

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

> счастливый - у нас накладывается более 20.

Честное слово, интересно. Какие? Для чего?
Пожалуйста расскажите, это же не тупой флейм, похоже здесь заинтересованные люди, нет огров и наоборот - авелей. Если не хочется писАть сюда, готов дать адрес.

> А просто в /dev/null писать почту для тех кого нет в системе и отправлять обратно
> уведомление что почта не принята не решит проблему
Наивный чукотский юноша :)
никогда спам из Китая или с американского карточного adsl или ещё откуда из Зимбабве
не получали сразу на все свои "засвеченные" адреса которых уже с полгода как нет?;-)
вот потом в стандартном qmail он всю эту ботву пытается засунуть обратно "отправителю" - которого может (уже) и не быть. В результате все отлупы огребает тот кто за MAILER-DAEMONа. :-( В стандартном sendmail такого быть ПРОСТО не может. :-)

второй довод - зачем мне вообще платить за трафик несуществующих пользователей (бывало в месяц до 50% от общего почтового трафика доходило)? а так дошло до RCPT TO: - и до
свиданья!

Про возможность работы djbdns и ipv6 читаем тут: http://www.fefe.de/dns/

> killa6.html
я с djb не согласен про glueless zones: мне вовсе не улыбается из-за каждого
клиента при изменении IP одного из наших NS переписывать несколько десятков записей
в РосНИИРОСе. Собственно, для того DNS и придумали чтобы к IP не привязываться везде.
А так - выдал раз и навсегда менеджеру список наших NS - и телемаркет!

> исходники djb нормально читаемы как таковые но комментарии там встречаются крайне редко
> уже из-за одного этого я не соглашусь что он отличный C-программер

Писание комментариев завист от потребностей в них. Я знаю, что
в больших конторах требуют комментарий чуть ли не через каждые три строчки.
В его случае писатель один и отчитываться ему не перед кем. Пишет он очень чисто.
Свой код знает наизусть. Я бы сказал наоборот: чем больше комментариев в коде, тем
менее тот программер понимает, что он делает.

> в исходном виде qmail совершенно непригоден (как я уже говорил) к массовой установке

Ты не знаешь qmail в таком случае, что неудивительно судя по твоим репликам.
Правила приема почты для qmail можно описать одним файлом и спокойно распространять
его хоть на тысячу машин.

> Эй, кто-нибудь знает альтернативу для dhcp?

Есть. Я знаю как минимум две альтернативные реализации. Но не скажу ;) Ищи сам.

> А кто эти глюки искал? Сколько юзающих оное ПО?

"It works for citysearch.com. It works for pobox.com. It works for Namezero,
the largest domain-hosting company on the Internet, which handles
more than 2 million .com's and .net's and .org's. It'll work for you too."
[http://cr.yp.to/djbdns/blurb.html]

Обрати внимание на последнее предложение в цитате ;)
Известно так же, что djbdns используется на одном из корневых серверов dns.

> Я программировал гораздо более простые вещи, а ошибки, пусть и не критичные, все равно выползали!

Кто есть ты такой? Никогда не задавался таким вопросом?

> Исходники dj... весьма непросто читаемы....

Для кого? Опиши нам умственные способности такого индивидуума...

> если кому понадобится "поправить" чего без меня: то скорее спец по ним найдётся, нежели по dj...

Без тебя они скорее поставят djbdns. И настроят за полчаса то, на что у тебя ушли месяцы...

>> выложить a-la "sendmail killer"
> мне интересно, выложи плиз

ftp://ftp.cf1.ru/pub/linux/qmail.spec (там же лежат нужные SRPMs)
сразу предупреждаю:
1) если djb наедет - я сразу уберу RPM (выкладывание пачей и спеков - это законно, хотя и несколько неудобно)
2) RPM ещё сыроваты и пока отлаживаются
пожелания, предложения и критика - принимаются: < byg @ cf1.ru> (пробелы уберите в email)

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

> Честное слово, интересно. Какие? Для чего?
ссылку тут дал на ftp - если чего непонятно для чего - спрашивайте.
в принципе, почти все пачи простые и понятные сразу.
BTW, я КРАЙНЕ рекоменжую для qmail приложить какой-ниубдь (какой больше подойдёт)
про HELO FQDN.:-)

2anonymous (*) (2002-05-22 20:02:07.263)

а на по барабану другие провайдеры 8-) Мы сами провайдеры... И нас прекрасно видно по ИП6 с запада.

2anonymous (*) (2002-05-23 06:16:08.815)
Прочитал. И нафига это надо? ставить патчи от хрен знает кого? если это все в БИНДе есть по умолчанию... 
Вдобавок там ничего не говорится про A6 записи, которые пришли на смену АААА.
А еще я так понял, что "поделка от DB" не умеет ixfr? бедненькие... сложно вам наверно...

2 anonymous (*) (2002-05-23 06:38:49.082)
> Известно так же, что djbdns используется на одном из корневых серверов dns.

На каком? Ссылку плз! Если можно. Правда, просто очень интересно!

> Кто есть ты такой? Никогда не задавался таким вопросом?

Задавался с самого детства! Как минимум не anonymous! И не считаю себя глупее DJB, хотя, я явно не такой "спец" в обсуждаемых вопросах. Спрорить о том, насколько я крутой программер не собираюсь. Но то, что писать без ошибок невозможно - это факт.

>BTW, я КРАЙНЕ рекоменжую для qmail приложить какой-ниубдь (какой больше подойдёт) >про HELO FQDN.:-)

а какие проблемы в HELO FQDN ??

> а какие проблемы в HELO FQDN ?
проблемы в его отсутствии ;)
~80% спама отсеивается, причём проверка - элементарная

> а какие проблемы в HELO FQDN ? >проблемы в его отсутствии ;) >~80% спама отсеивается, причём проверка - элементарная

ааа это когда проверятся наличие домена отправителя ??

> вой код знает наизусть. Я бы сказал наоборот: чем больше
> комментариев в коде, тем менее тот программер понимает,
> что он делает

послушайте, иногда ведь программы правятся не теми кто их писал. на эту тему хорошо высказался Керниган - надеюсь, знаете, кто он такой?;) если интересно - я Вам процитирую.по крайней мере отсутствие нормальных комментариев в PHP в сравнении с тем же PostgreSQL сильно затрудняет процесс правки. Относительно qmail могу сказать что иногда его (djb) логика с лёту непонятна и если бы была написана хотя бы строчка-намёк - это экономило бы несколько минут работы.
поэтому "программист, не пишущий комментариев - не может быть отличным" - это аксиома, проверяемая годами опыта либо
доверием к опыту других людей.
> Ты не знаешь qmail в таком случае, что неудивительно судя
> по твоим репликам. Правила приема почты для qmail можно
> описать одним файлом и спокойно распространять
> его хоть на тысячу машин.
я себе прекрасно представляю о чём говорю и вполне осознаю
что к чему.sendmail.cf "спокойно распространяется" на миллионы машин - и что? кроме того, это чистой воды гон, потому что для того чтобы сделать хотя бы 1 вирутальный домен в .qmail понадобится min 2 доп. файла, не говоря уже
про badmailfrom, badrcptto (который, кстати, без пача не сделаешь - вот тебе уже и 1 пач). примеры можно продолжить.
впрочем что от онанимуса ожидать?;)
позиция djb в таких случаях известна - "мне это не надо, поэтому не надо никому" - однако он никому не запрещает
делать и распространять свои пачи.
> Я знаю как минимум две альтернативные реализации. Но не
> скажу
редиска, кажи, сэкономишь время на поиски. я за сегодня уже нашёл три, но 2 из них точно >/dev/null.

народ, как я понял, то djbdns не имеет динамического апдейта, что плохо. если делать интеграцию разных ос, то ms поддерживает dymanic updates + записи хранятся в unicode. а как у unix dns c хранением записей в unicode? горбуха в том, что ms сделало шаг в одном направлении (unicode, как следствие возможность создание доменов в национальных кодировках, другое дело нафиг такое нужно), а под unix поддержка ipv6, опять нафиг оно нужно, т.к. большинство клиентов (с этим нельзя не согласиться) находяться по ms, а там пока ipv6 не пахнет, да еще, не знаю, как в линуксе, но в openbsd оторвать ipv6 от ipv4 не получится.

У djbdns записи хранятся в бинарной базе данных. Это вам не какие-то текстовые файлы, будь они хоть трижды юникодные.

А что в вашем понимании динамический апдейт? А то все "динамический апдейт, динамический апдейт" а че такое хз.

А в твоем понимании что это такое?
Может хотя бы RFC почитаешь, доку к тому же DHCPd или BIND'у. Там прямо в исходниках дока есть - в ней все и расписано! :)

> то когда проверятся наличие домена отправителя ?
да.
причём это наглядный пример обычной политики djb:
"я не считаю, что HELO нужно - пофигу мне rfc821"

>> Исходники dj... весьма непросто читаемы....
> Для кого? Опиши нам умственные способности такого индивидуума...
Обыкновенные способности, несколько повыше чем у Вас. уважаемый :)

>> если кому понадобится "поправить" чего без меня: то скорее спец по ним найдётся, нежели по dj...
> Без тебя они скорее поставят djbdns. И настроят за полчаса то, на что у тебя ушли месяцы...
И за это получат пинок с разбега по яйцам, потому как:
1) Я никогда не отсутствую долго (пинок от меня)
2) Будет прервана нормальная работа системы (пинок от ряда заинтересованных лиц)...
Месяцы на настройку? Вы точно, уважаемый, не в себе :) Хамите, однако, по ананимской традиции... :)

> djbdns не имеет динамического апдейта, что плохо
и чем же это плохо? нафиг он нужен - сделан из-за
ленивых / криворуких IT работничков.:-)
плюс к тому же плодит дыры наподобие нашего гоярчо любимого топика.;-)
единсвтенное возможное применение - для зваедения доменов через веб - и то это не нужно djbdns где это делается гораздо изящнее, да и named тоже может обойтись без этой ботвы.

>> то когда проверятся наличие домена отправителя ? >да. >причём это наглядный пример обычной политики djb: >"я не считаю, что HELO нужно - пофигу мне rfc821"

да жаль :-( а не знаешь можно ли сделать антивирусной проверку пролетающих через сервер мессаг т.е. если сервер релеем работает ??

>> а какие проблемы в HELO FQDN ?
> проблемы в его отсутствии ;)
> ~80% спама отсеивается, причём проверка - элементарная

Теоретически я могу написать в helo что угодно, например, helo rambler.ru.
Твоя сеялка-веялка отсеет меня? DJB не утруждает себя ревлизацией бесполезных фич.
Ни один из параметров, передаваемых в заголовке реально нельзя проверить на подлинность
без криптографической подписи. А следовательно, все такие проверки - филькина грамота.
К тому же, есть случаи когда приходится общаться с технически неграмотными, но
денежными клиентами. Просто так рубить их из-за кривого helo - себе дороже...

Спам в qmail'e легко рубится по IP, по маске сети, по регекспам, которые можно прменить к письму,
а также по данным, полученным от стороннего RBL. Вполне достаточно, тем более, что все это
работает из коробки.

Ура! Во всех обсуждениях НИ НОДНОГО СЛОВА ПРО БЛИНД! Только DJB! Мир изменился к лучшему!

> Обыкновенные способности

Я так и знал ;(

> 1) Я никогда не отсутствую долго (пинок от меня)

Понимаю... при обыкновенных способностях нужно очень крепко держаться за место ;)

> 2) Будет прервана нормальная работа системы (пинок от ряда заинтересованных лиц)...

А может быть она впервые станет нормальной? И "ряд заинтересованных лиц" поймут,
что кто-то работал не на своем месте ;)

> послушайте, иногда ведь программы правятся не теми кто их писал

Относительно qmail и прочего djb-софта хочу тебя успокоить сразу.
Согласно его (отсутствующей) лицензии ты не имеешь права распространять
измененный продукт. Это не GPL и не BSD и не Public Domain. Это настоящий
proprietary soft с _доступными_ (а не открытыми!) исходниками. Такие понятия
нужно четко различать.

Тексты даются в первую очередь для того, что бы _грамотный_ сисадмин мог
с ними ознакомиться и убедиться в отсутствии закладок и явных дыр в безопасности.
Сейчас понял? И боже тебя упаси править там что-либо ;)

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

> для того чтобы сделать хотя бы 1 вирутальный домен в .qmail понадобится min 2 доп. файла
Это да, два файла. Я думал ты говоришь про про правила "от кого принимать", а не "для кого".
Картина не меняется в-общем. Про "sendmail.cf "спокойно распространяется на миллионы машин"
сомнения берут однако.

> про badmailfrom, badrcptto
Очень ненадежные параметры для фильтрования. Я их почти не использую.

> однако он никому не запрещает делать и распространять свои пачи.
Да, но по-настоящему ценных патчей очень мало. Я посмотрел твой qmail.srpm.
Дерьмо на палочке. Единственный патч, о ценности которого можно поспорить -
это auto_uid. Ну еще condredirect. Остальное туфта. Особенно позабавил qmail-1.03-redhat.patch ;)
В guide_to_relaying_RUS.txt написана откровенная лажа про то, что без файла rcpthost
qmail становится открытым релеем. Короче, жуткий сброд ненужных или утаревших патчей.

mumpster, спасибо за ссылку. Как минимум один патчик я применю.

> не имеешь права распространять измененный продукт
я знаю. это есть основная проблема с его прогами для
включения в дистры. но меня это смущает слабо - я вполне могу обходиться SRPMs или их аналогами в других системах.
BTW, qmail SRPM - абсолютно законно (см. cr.yp.to )
> боже тебя упаси править там что-либо
и что будет если я что-нибудь там поправялю и
выложу пач на всеобщее обозрение?;)
djb засудит что-ли?
> можешь нанять грамотного специалиста, который легко
> прочитает и поймет
ага - и сразу же пропачит когда въедет в ситуацию

> можно ли сделать антивирусной проверку пролетающих через > сервер мессаг т.е. если сервер релеем работает? где, в qmail? да, можно, но нужно будет немного повозиться в sendmail есть milter на ту же тему как в postfix и exim - не знаю, но подозреваю что тоже несложно

Такой забавный базар. Типа DJB'исты говорят: "На х.. то, на х.. это и т.д." IPv6 им не нужен ...
Здравый консерватизм несомненно полезен, но когда он перерастает в маниакальный пох...зм. Динамический апдейт им видите-ли не нужен (одни дыры из-за него), IPv6 - игрушка для увлеченных. Так бы и ездили до сих пор на лошадях, так нет же - автомобиль пользуем, хотя и он не без недостатков. Но ездить на работу каждый день на коняшке меня не "прикалывает".

> Очень ненадежные параметры для фильтрования. Я их почти
> не использую.
чем же адрес получателя ненадёжен? мне вовсе из своего карман не хочется платить за трафик на fired-two-years-ago-employee@our.domain
а так как только дело доходит до адреса получателя: 5xx - и телемаркет.:) адрес отправителя - хотя и не очень эффективно, но свои 10-20% от общего кол-ва спама режет, причём не напрягаясь.
> Дерьмо на палочке
я никого насильно не заставляю пользоваться. не нравится - не ешь.
> Особенно позабавил qmail-1.03-redhat.patch
и чего там такого забавного? то что документированы отличия от "стандартных" (читай a-la sendmail) систем? так это наоборот хорошо - даже незнакомый с djb quirks человек сможет быстро войти в курс дел. не понимаю, чем это может быть плохо?
> откровенная лажа про то, что без файла rcpthost
> qmail становится открытым релеем
пржде чем что-то заявлять, неплохо бы проверять свои слова - вот возьми, прибей rcpthosts (с s на конце ибо во множественном числе) и посмотри результат. Его сообщи зедсь нам.;-)
vidal sasoon.

> И НОДНОГО СЛОВА ПРО БЛИНД bind, bind, bind, bind...=) а если серьёзно - у меня уже много претензий к bind накопилось и к dhcpd. BTW, там никто ссылочками и не поделился про альтернативные dhcpd, жаль.

> Динамический апдейт им видите-ли не нужен
а объясни нам, действительно звчем он нужен?
в нормальной сети все машины должны быть пересчитаны, описаны
и unknown clients быть просто не должно => ip
у каждой машины извсетно заранее (apriori) и в DNS можно
просто прописать нужные имена.
ещё в 1995 г. были видны "родимые пятна" DHCP в виде проблем с безопасностью.

dynamic updates их лишь усугубляет.

Нормальная сеть - она в мечтах. Или в "застойных" конторах. А у меня, к примеру, любая машина из сети может быть на "лету" продана по частям или целиком (специфика фирмы). И я должен бросать све дела и скакать править конфиги? И это рабочие "тачки". А есть еще игровой сегмент сети - так там безопасность на х.. не нужна, зато смена машин идет постоянно! Сегодня там P4 с DF2, завтра какой-нибудь GF4 поставят. И мне из-за такой херни отвлекаться?
На ответственных местах "unknown clients" и у меня нет, только, думать еще и об IP я не собираюсь - пусть DHCP их раздает (хотя, статические IP я тоже пользую).

> dynamic updates их лишь усугубляет.
Любую систему усугубляет ее усложнение. Но, со временем проблемы решаются...

Другие примеры DDNS пусть еще кто-нибудь приведет. Мне тоже интересно послушать. :)

> Понимаю... при обыкновенных способностях нужно очень крепко держаться за место ;)

Обо всех по себе не судите :) Можете сами приходить: я вам с удовольствием уступлю "своё место" - вперёд и с песней... Только вот желающих мало... А... извините, вы же гений программирования, поэтому и прячетесь за анонимной вывеской :)...

> А может быть она впервые станет нормальной? И "ряд заинтересованных лиц" поймут, что кто-то работал не на своем месте ;)
Заинтересованные лица - это не руководство, руководству по... - им нужно другое: чтоб бабки не тратили, грызлись меж собой... Разделяй и властвуй ...:)... А поставят, не dj... - а винду какую-нить :)...

>anonymous (*) (2002-05-24 02:58:47.053)
АА... :) Всё ясно ...

> чем же адрес получателя ненадёжен? мне вовсе из своего карман не хочется платить за трафик на
> fired-two-years-ago-employee@our.domain

Ну и зря. Я бы оставлял такие письма для просмотра. В них может быть ценная информация от
потенциальных клиентов, а может быть нечто, что заинтересует службу безопасности ;)
На счет "из своего кармана". Как известно, smtp трафик занимает ничтожный процент
по сравнению с остальными видами трафика. Так что экономия сомнительная.

> и чего там такого забавного? то что документированы отличия

То, что redhat в своем амплуа - в вечной заботе об luser'ах ;) К тому же пересказ
документации - очень плохие манеры.

>> qmail становится открытым релеем
> пржде чем что-то заявлять, неплохо бы проверять свои слова

Каюсь. Не проверял. Просто был уверен. Оказалось, что это не так. Иногда вредно читать
доки ;( В исходниках qmail есть файл PIC.relaybad. Там пример такой:
-------------------
qmail-smtpd Receive message by SMTP from another host:

MAIL FROM:<spammer@aol.com>
RCPT TO:<bill@irs.gov>

Is $RELAYCLIENT set? No.
Is irs.gov in rcpthosts? No.
Reject RCPT
-------------------
Из этого я делал вывод, что при отсутствии rcpthosts qmail не должен вообще никого релеить.
А когда взглянул в исходники, оказалось, что пустой файл rcpthosts и его полное
отсутствие обрабатываются системой по-разному.
Это не то, чтобы баг, но явная логическая неувязочка.

> Можете сами приходить: я вам с удовольствием уступлю "своё место" - вперёд и с
> песней... Только вот желающих мало...

Дык все ясно без слов тогда. Я знаю только одну причину такой ситуации - на том месте
платят так много денег, что стоять за прилавком на базаре оказывается намного выгодней ;)
Мои соболезнования...

По поводу dynamic dns есть некоторые подвижки и даже рабочие варианты для djbdns:

- есть tinydns backend для gnudip - http://gnudip2.macdonnell.ca/
- есть интересное решение pop-before-dyndns - http://innominate.org/projects/tinydyndns/

mumpster (*) (2002-05-24 14:35:27.191): если это не нужно Вам - это не значит, что это не нужно никому, правильно? ;) А штучка в связке с DHCP очень нужная. Кстати, насчёт дыр - апдейт, насколько я помню, можно криптовать. Ну и, естественно, апдейты принимать с доверенных хостов (с DHCP сервера вот, в самом простом случае).

Ага. Прямо с localhost и принимать! :) А уж update криптовать - святое дело! Вот только с хранением ключей кажется не все блестяще :(

Динамический днс.

http://www.thismetalsky.org/magic/projects/dhcp_dns.html

How's it work?

Okay, this is really easy. We have the djb_update.pl program, running as a daemon. This thing watches the DHCPD lease file, and when it changes, we start processing. The lease file will get updated every time a machine asks the server for an address. So when that happens, dns_update.pl will go through the lease file, pull out the addresses, and stuff them into a tinydns zone file fragment, merge the fragment with your static address, and import it into a tinydns data file.

Поставил. Работает.

> в них может быть ценная информация
угу - "enlarge your penis" и "недвижимость на Канарах";-)
> smtp трафик занимает ничтожный процент

согласен. но только если в процентах. если пересчитать на Гбайты, а тем более на деньги - чоень даже ничего набегает.:-(
А если у тебфя есть 20-30 лишних баксов в месяц (средние ежемесячные затраты на такую почту) - может высылать мне.:-)
> не то, чтобы баг, но явная логическая неувязочка
напиши djb. IMHO если файла нет - сам дурак.:)

> апдейты принимать с доверенных хостов гм - порочна сама идея - что клиентская машина САМА определяет как ей называться. Вот это причина DDNS. Если интересно, на www.isoc.org было 2 статьи на тему DHCP от 1995 и 1997 гг в одной из которой все слабые места DHCP были ещё тогда перечислены. Средств борьбы нет до сих пор.;-)

Забавно наблюдать, как расходятся по воде круги от хорошего флейма. DJB -- классный флеймер. Старая школа. В web-форумах такого не найдешь, только в Usenet, иногда в FIDO. Анонимусы в web-форумах думают, что высказывают свое мнение, а на самом деле они -- только круги на воде.

Ну да. Все вокруг типа дураки - пользуют софт от ISC. Когда крутые кулхацкеры юзают чумовую вещь от DJB! И плевать им на все новые фичи, плевать, что IP-адреса скоро кончатся.