>Статья о том как избавить себя от постоянных апдэйтов BIND

заодно статься о том, как избавить себя от нормального, полнофункционального ДНС-сервера...

Народ, не надо курить дешевую траву и раздавать ссылки на тупые
howto. После таких статей списки рассылки завалены тупыми
вопросами. Есть официальная документация, более чем подробная
и достаточная для установки djbdns и замещения bind.
Вот она вся здесь: http://cr.yp.to/djbdns.html

руки прочь от bind ламаки

Да, доебDNS нам не нужун!

Может быть djbdns на самом деле супер секурный, но вот код его больше напоминает жуткие математические выкладки, записанные на куче маленьких листиков. Стоит обновиться RFC1035, как Бернштейну понадобиться еще 3 года, чтобы что-то в него добавить.

Чтоб туда что-то добавить не нужно быть djb и не нужно править код djbdns и перекомпиливать тоже не нужно, там есть гибкая система плугинов. Написал плугин, присоединил и все.
А rfc1035 уже 15 лет (с 1987г) не обновлялся и в ближайшие 15 лет и не обновится, вы озабачиваетесь проблемами которых нет.

=) Посмотрим как скоро там хотя бы ipv6 реализуется.

Кроме rfc1035 есть 3226, 3110, 3008 и много еще чего интересного и полезного.

Бинд и сервак с будкой для админа отлично заменяют нормальную половую жизнь. Бинд рулез фореве и форнахуй !

Спешите увидеть !

Битва титанов !

Дохтура Бернштейна бьют по голове !

Флейм века "bind vs djbdns" на

http://www.isc.org/ml-archives/bind-users/2000/08/threads.html#01075

Саныч

2Саныч: А где там по голове - это про "Смешные аргументы юзеров блинда про суппорт " ? Юзали бинд с 1998 года. В январе 2001 года нам сбивали бинд после обьявления про очередные дырки. С тех пор у нас djb. Обслуживает 9 С-сеток и юзеров при них. Проблем нет. Файлы конфигураций значительно проще , изменения вносить легче ... днс софт не обновляется с того-же января 2001 ...

2anonymous (*) (2003-03-22 18:53:00.771524)

Там, где по голове - это про неумение djb делать ничего. Ни тебе dynamic updates, ни IXFR, ни IPv6, ни TSIG, etc, зато есть детский лепет про rsync. Пионерская поделка. А про 9 C-сеток ты маме расскажешь. Будешь тысячи зон держать - тогда послушаем.

Надо же анонимусы тысячи зон держат ;)
Не смешите мои тапочки.

А axfr djbdns умеет прекрасно.
А ipv6 в интернете нет и в ближайшем будующим и не будет, вчастности и из-за того что не могут ничего нормального придумать как привязать ipv6 к dns. Сначала придумали АААА оказалось нерабочим by desing и сдохло (тоже вони было от любителей бинда, им сразу приспичило иметь АААА), потом А6, DNAME и т.п. и на смену им еще придет не один нереализуемый draft.
Зачем анонимусам понадобилать dns поддержка для ipv6 которым еще не ходит по инету и я боюсь что в ближайшие 5 лет даже не начнет внедряться, для меня лично загадка.

В общем одни еще вчера, сегодня, завтра работают реально в инете с dns серверами, а другие все гоняются за новомодными фичами.

anonymous (*) (2003-03-22 19:45:06.156804)

1. Держат, представь себе. 2. Речь не про AXFR, а про IXFR. Марш читать RFC1995. 3. Насчет нереализуемых драфтов - это в IETF. Анонимусам поддержка IPv6 нужна - хотят себе IPv6 четей отхапать. 4. Так как насчет dynamic updates, IXFR, IPv6 и TSIG ? 5. Если тебе оно не нужно, то это еще не значит, что оно никому не нужно. Для тех, кому нужно, djb - поделка. 6. В сад.

5 баллов. Присоединяюсь.

Мне от DNS много надо. Я отдаю себе отчет в том, что будет это не без глюков.

Пусть DJBDNS живет. Наверно это кому-то надо.

In July 2002, IETF downgraded the A6, DNAME, and bit-label specifications (RFC 2874 and RFC 2673) from Proposed Standard to Experimental: ``A6, Binary Labels and DNAME DNS extensions should not be widely deployed for use with IPv6 at this time.''

Т.е. по сути дела A6 и DNAME дропнули так же как и AAAA раньше. Уже понятно что те кто начинают строить свои сети на A6 просчитались, потому что вряд ли когда-нибудь он станет стандартом.

Поэтому никакого смысла нет для djbdns поддерживать experimental протоколы от которых IETF по сути дела отказалось.

А поделка это дырявые dns серверы основывающиеся на эксперементальных протолах.

набираем на гугле bind & TSIG - дальше невозможно сосчитать bug & exploit. впрочем, если кто хочет выебываться над юзерами ставьте свой уебистый бинд и пиздуйте в будку при сервере.

9 сеток с реверсе - это более 4 тыс записей, кого-то секондарим. Не сомневаюсь что песня про "тысячи зон" сложена про записи вида: vasya.dolboeb.ru . Сообщи плс сколько из них реально работает ? Если же это общественный днс секондари так твое заявление еще смешнее.

<цитата> А про 9 C-сеток ты маме расскажешь. Будешь тысячи зон держать - тогда послушаем </цитата>

Вот как раз на больших обьемах данных djbdns то и выигрывает. Такое ощущение, что вы читали тольло те сообщения из приведенного обсуждения, где ругают dbjdns. И как-то пропустили все остальное.

2walrus:

Ничего я не пропустил. Диджей там пел песню про то, что у bind ощутимая задержка при загрузке большого количества зон, на что ему справедливо указали, что существует 9 bind, который умеет грузить зоны и отвечать на запросы одновременно.

2любителям поиска в гугле:

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

2лох: Про секурити в djb и плагины (наверное имеются ввиду патчи) - очень смешно, ты будешь первым кто нашел проблемы . что именно умеет без глюков бинд ? Какая версия бинда не имеет секьюрных проблем ? Поэтому ребята, втирайте и мамам и тапочкам и про тысячи зон и про фичи и делайте жутко умное ебло с IPV6 вместе ! Нехера у вас нормально работать не будет и сидеть вам в будке без половой жизни пока и вас БИНД - рулез фореве !

ну если только наружу djb выставить, т.к. там все равно многого не нужно. лично я, после установки одного из серверов внутри сети на djb через час поимел массу приключений - если djb resolver чего-то не находит, то он начинает заниматься тривиальным флудом. количество запросов где-то порядка 40-100 пакетов в секунду, причем хотя ему отвечают, что нет такой записи, он просто игнорирует ответы и продолжает долбиться.

> Ничего я не пропустил. Диджей там пел песню про то, что
> у bind ощутимая задержка при загрузке большого

я что-то пропустил ? DNS теперь принято перегружать раз в пять минут ?

2{40-100 пакетов}: а как должен себя вести рекурсивыный кэш при долбоебических запросах ? это известная днс проблема. Выбери из логов идиотские домены (как правило название фирм пользователей) и пропиши в servers/ пустые файлы с такими именами ;)

> я что-то пропустил ? DNS теперь принято перегружать раз в пять минут ?
Да, ты пропустил целую вечность. Наверное проспал в анабиозе.
На сервере, обслуживающем тысячи доменов загрузка может длиться
несколько десятков минут.

DJBDNS - Dump Journal Blocks of the Dead Nigger Storage (c) один из lkml :)

Если djbdns -- такой хороший, секьюрный, и т д, и т п -- то почему он не используется так широко как bind? -- ответы что все мудаки а мы используем djbdns -- самые умные -- заведомо не верны -- выходит, что хуйня ваш djbdns =)) И потом -- да, у бинда бывают проблемы, но все эти проблемы решаются -- правильной конфигурацией, и постоянным аудитом серверов -- если вы админ, конечно а не так себе, читайте мануалы, факи, рфс -- и когда прочитаете, то тогда и ругайте бинд, не умеете работать с бинд, так это ваши проблемы, а не проблемы бинда. а подобного рода поделки (djbdns) -- засуньте себе в сраку, право, обидно стало. Прошу заранее прощения, если кого обидел.

>>почему он не используется так широко

по тем же причинам что и sendmail более распространен чем qmail, просто раньше появился.

на то он и кэш, чтобы ответы кэшировать, в том числе и negative.

<цитата> Если djbdns -- такой хороший, секьюрный, и т д, и т п -- то почему он не используется так широко как bind? -- ответы что все мудаки а мы используем djbdns -- самые умные -- заведомо не верны -- выходит, что хуйня ваш djbdns =)) </цитата>

djbdns никогда не будет так распространен как бинд, хотя бы потому, что у части населения Бернстайн вызывает сильную аллергическую реакцию. Однако это не значит что djbdns обьективно хуже бинда. Строго говоря по наиболее важным параметрам - защищенность, масштабируемость, легкость настройки - djbdns обьктивно _лучше_ бинда.

<цитата> то тогда и ругайте бинд, не умеете работать с бинд, так это ваши проблемы, а не проблемы бинда </цитата>

Большинство из тех, кто работат с djbdns - имеют опыт работы с bind, а вот большинство из тех, кто предпочитает bind - ничего кроме bind и не видели. Кстати одна из основных причин перехода на djbdns - это то, что bind требует слишком большое внимание к себе (необоснованно большое) - постоянные upgrade, постоянные проблемы с безопасностью и тд. (Это камень в огород вашей фразы о постоянном аудите серверов.)

<цитата> а подобного рода поделки (djbdns) -- засуньте себе в сраку, </цитата>

Спасибо, я уже оценил ваш стиль аргументации.

<цитата>я что-то пропустил ? DNS теперь принято перегружать раз в пять минут ? </цитата>

Весь вопрос в масштабах. Если у вас один домен - то перезагрузка - не проблема. Если у вас тысячи доменов - то практически не проходит и дня, чтобы хотя бы в одном из доменов не поменялись данные. И в этм случае у djbdns преимущество за счет .cdb файла

Кто нибудь юзет альтернативные корневые сервера (ORSC)? Поделитесь ощущенями ? Насколько это стабильно и надежно ?

На самом деле, флейм - отстой.
"Upgrading to BIND version 9.2.2 is strongly recommended. If you cannot upgrade, BIND 8.3.4, 8.2.7, and 4.9.11 are available."
Так вот... Если я на девятку из-за ужесточившихся правил для конфигов не могу перейти, то что уж о djbdns говорить????
Вот так-то...

очень просто - отдаешь новому днс серверу джб или бинд зону, а он сам запишет данные в своем новом формате.

> 2{40-100 пакетов}: а как должен себя вести рекурсивыный кэш при
> долбоебических запросах ? это известная днс проблема.

Что тут известного? Схождение с ума? Не должно оно сходить с ума.
А лечить это введением дурных пустых зон - да, вот она мудрость
фанатов, во всей красе...

Кстати, named на 12 тысяч зон есть тут в пределах моей видимости, и никакого многочасового вставания у него нет... 8.3.4-release.
Так что если у кого-то оно час думает - ищите другую проблему...

DJBDNS

<цитата>
Что тут известного? Схождение с ума? Не должно оно сходить с ума.
</цитата>

А оно и не сходит. Та ситуация. которую тут описали пусть останется 
на совести авторов. Потому что dnscache кеширует отрицательные 
ответы безо всяких проблем. У меня куча мест, где работает dnscache 
и я ни разу не видел ничего подобного. 


Вот вам пример:

придумаем домен и сделаем пинг на него:

[walrus]$ time ping hrenvam.ru
ping: unknown host hrenvam.ru
Command exited with non-zero status 2
0.00user 0.00system 0:00.26elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (209major+36minor)pagefaults 0swaps

Второй раз:

[walrus]$ time ping hrenvam.ru
ping: unknown host hrenvam.ru
Command exited with non-zero status 2
0.01user 0.00system 0:00.01elapsed 83%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (209major+36minor)pagefaults 0swaps


Как видите второй раз - отсутсвие домена определилось в 26 раз 
быстрее.


теперь в логах: после первого пинга:

@400000003e7f0e3520178da4 query 47 xxxxxxxx:8003:183b 1 hrenvam.ru.
@400000003e7f0e352017c454 cached ns ru. ns.ripn.net.
@400000003e7f0e352017d00c cached ns ru. ns1.relcom.ru.
@400000003e7f0e352017d7dc cached ns ru. ns2.nic.fr.
@400000003e7f0e352017e394 cached ns ru. ns2.ripn.net.
@400000003e7f0e352017eb64 cached ns ru. sunic.sunet.se.
@400000003e7f0e352017f71c cached ns ru. auth60.ns.uu.net.
@400000003e7f0e352017feec cached 1 ns.ripn.net.
@400000003e7f0e3520180aa4 cached 1 ns1.relcom.ru.
@400000003e7f0e3520181274 cached 1 ns2.nic.fr.
@400000003e7f0e35201a6434 cached 1 ns2.ripn.net.
@400000003e7f0e35201a73d4 cached 1 sunic.sunet.se.
@400000003e7f0e35201a7f8c cached 1 auth60.ns.uu.net.
@400000003e7f0e35201a875c tx 0 1 hrenvam.ru. ru. c17d9803 c0247d02 
c2e2601e c2557701 c60601b5 c05d0004
@400000003e7f0e352dd252e4 nxdomain c17d9803 3600 hrenvam.ru.
@400000003e7f0e352dd28d7c sent 47 28


После второго пинга смотрим:

@400000003e7f0e3c039d54c4 query 49 xxxxxxxx:8003:d261 1 hrenvam.ru.
@400000003e7f0e3c039d878c cached nxdomain hrenvam.ru.
@400000003e7f0e3c039d9344 sent 49 28


то есть проблема высосана из пальца. Все нормально отрабатывает.

кстати. тока что пришло мне мыло(хотя новость похоже старая).
всем кто говорит, что IPv6 нигде не применяется...
http://www.v6.eu.ntt.net/news/20030219/newsrelease.htm

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

Не надо путать IPv6 и его существующую поддержку в dns ввиде A6 от которого скорее всего откажутся. IPv6 скорее всего будет хоть не скоро, все к этому идет, а А6 скорее всего не будет, к этому тоже все идет, и поддержка сейчас А6 выглядит сомнительной и не нужной.
Кому нужно пожалуйста, пусть ставят себе что угодно и гоняют что угодно, но орать что А6 по зарез всем нужно и что это вообще суперфича, это тыкать пальцем в небо.

hrenvam.ru - не очень соответствует описанному случаю, надо с обращением к корневым серверам: XX1.myfirm при этом маздайкин софт не должен воспринимать днс-ответы - это типовой вариант с всевозможными глюкавыми виндовс-ускорителями. К сожалению единственный способ лечения - это не пускать таких юзеров к кэшу или возвращать ложные ответы или брать с ORSC _все_ домены первого уровня и никогда не отдавать юзерам ссылку на корневые сервера иначе каналу звездец. Ясно, что начиная с определенной конфигурации трудно понять где интернет снаружи или внутри узла ;)

про ipV6 - описана хорошая сетка без соеденений с ipV4. Им лента.ру и анекдот.ру не нужны, а мы при такой конфигурации потеряем доход ...

> dnscache кеширует отрицательные ответы безо всяких проблем.

У тебя явно старая версия djbdns. В версии 1.05 отрицательные
ответы уже не кешируются. И на это есть причина.

У меня именно 1.05 стоит. И логи я привел из 1.05.