Народ, не надо курить дешевую траву и раздавать ссылки на тупые
howto. После таких статей списки рассылки завалены тупыми
вопросами. Есть официальная документация, более чем подробная
и достаточная для установки djbdns и замещения bind.
Вот она вся здесь: http://cr.yp.to/djbdns.html
Может быть djbdns на самом деле супер секурный, но вот код его больше напоминает жуткие математические выкладки, записанные на куче маленьких листиков. Стоит обновиться RFC1035, как Бернштейну понадобиться еще 3 года, чтобы что-то в него добавить.
Чтоб туда что-то добавить не нужно быть djb и не нужно править код djbdns и перекомпиливать тоже не нужно, там есть гибкая система плугинов. Написал плугин, присоединил и все.
А rfc1035 уже 15 лет (с 1987г) не обновлялся и в ближайшие 15 лет и не обновится, вы озабачиваетесь проблемами которых нет.
2Саныч: А где там по голове - это про "Смешные аргументы юзеров блинда про суппорт " ? Юзали бинд с 1998 года. В январе 2001 года нам сбивали бинд после обьявления про очередные дырки. С тех пор у нас djb. Обслуживает 9 С-сеток и юзеров при них. Проблем нет. Файлы конфигураций значительно проще , изменения вносить легче ... днс софт не обновляется с того-же января 2001 ...
Там, где по голове - это про неумение djb делать ничего. Ни тебе dynamic updates, ни IXFR, ни IPv6, ни TSIG, etc, зато есть детский лепет про rsync. Пионерская поделка. А про 9 C-сеток ты маме расскажешь. Будешь тысячи зон держать - тогда послушаем.
Надо же анонимусы тысячи зон держат ;)
Не смешите мои тапочки.
А axfr djbdns умеет прекрасно.
А ipv6 в интернете нет и в ближайшем будующим и не будет, вчастности и из-за того что не могут ничего нормального придумать как привязать ipv6 к dns. Сначала придумали АААА оказалось нерабочим by desing и сдохло (тоже вони было от любителей бинда, им сразу приспичило иметь АААА), потом А6, DNAME и т.п. и на смену им еще придет не один нереализуемый draft.
Зачем анонимусам понадобилать dns поддержка для ipv6 которым еще не ходит по инету и я боюсь что в ближайшие 5 лет даже не начнет внедряться, для меня лично загадка.
В общем одни еще вчера, сегодня, завтра работают реально в инете с dns серверами, а другие все гоняются за новомодными фичами.
1. Держат, представь себе.
2. Речь не про AXFR, а про IXFR. Марш читать RFC1995.
3. Насчет нереализуемых драфтов - это в IETF. Анонимусам поддержка IPv6 нужна - хотят себе IPv6 четей отхапать.
4. Так как насчет dynamic updates, IXFR, IPv6 и TSIG ?
5. Если тебе оно не нужно, то это еще не значит, что оно никому не нужно. Для тех, кому нужно, djb - поделка.
6. В сад.
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. И как-то пропустили все остальное.
Ничего я не пропустил. Диджей там пел песню про то, что у bind ощутимая задержка при загрузке большого количества зон, на что ему справедливо указали, что существует 9 bind, который умеет грузить зоны и отвечать на запросы одновременно.
2любителям поиска в гугле:
Насчет секьюрити с djb весело - софт, который почти ничего не умеет без сторонних плагинов, вы в этих плагинах лучше дыры поищите. Диджей поступает просто - он пишет коре (возможно, неплохое), а грязную работу по реализации собственно протоколов оставляет другим.
2лох: Про секурити в djb и плагины (наверное имеются ввиду патчи) - очень смешно, ты будешь первым кто нашел проблемы . что именно умеет без глюков бинд ? Какая версия бинда не имеет секьюрных проблем ? Поэтому ребята, втирайте и мамам и тапочкам и про тысячи зон и про фичи и делайте жутко умное ебло с IPV6 вместе ! Нехера у вас нормально работать не будет и сидеть вам в будке без половой жизни пока и вас БИНД - рулез фореве !
ну если только наружу djb выставить, т.к. там все равно многого не
нужно. лично я, после установки одного из серверов внутри сети на djb
через час поимел массу приключений - если djb resolver чего-то не
находит, то он начинает заниматься тривиальным флудом. количество запросов где-то порядка 40-100 пакетов в секунду, причем хотя ему
отвечают, что нет такой записи, он просто игнорирует ответы и
продолжает долбиться.
2{40-100 пакетов}: а как должен себя вести рекурсивыный кэш при долбоебических запросах ? это известная днс проблема. Выбери из логов идиотские домены (как правило название фирм пользователей) и пропиши в servers/ пустые файлы с такими именами ;)
> я что-то пропустил ? DNS теперь принято перегружать раз в пять минут ?
Да, ты пропустил целую вечность. Наверное проспал в анабиозе.
На сервере, обслуживающем тысячи доменов загрузка может длиться
несколько десятков минут.
Если djbdns -- такой хороший, секьюрный, и т д, и т п -- то почему он не используется так широко как bind? -- ответы что все мудаки а мы используем djbdns -- самые умные -- заведомо не верны -- выходит, что хуйня ваш djbdns =)) И потом -- да, у бинда бывают проблемы, но все эти проблемы решаются -- правильной конфигурацией, и постоянным аудитом серверов -- если вы админ, конечно а не так себе, читайте мануалы, факи, рфс -- и когда прочитаете, то тогда и ругайте бинд, не умеете работать с бинд, так это ваши проблемы, а не проблемы бинда. а подобного рода поделки (djbdns) -- засуньте себе в сраку, право, обидно стало. Прошу заранее прощения, если кого обидел.
<цитата>
Если djbdns -- такой хороший, секьюрный, и т д, и т п -- то почему он не используется так широко как bind? -- ответы что все мудаки а мы используем djbdns -- самые умные -- заведомо не верны -- выходит, что хуйня ваш djbdns =))
</цитата>
djbdns никогда не будет так распространен как бинд, хотя бы потому, что у части населения Бернстайн вызывает сильную аллергическую реакцию. Однако это не значит что djbdns обьективно хуже бинда. Строго говоря по наиболее важным параметрам - защищенность, масштабируемость, легкость настройки - djbdns обьктивно _лучше_ бинда.
<цитата>
то тогда и ругайте бинд, не умеете работать с бинд, так это ваши проблемы, а не проблемы бинда
</цитата>
Большинство из тех, кто работат с djbdns - имеют опыт работы с bind, а вот большинство из тех, кто предпочитает bind - ничего кроме bind и не видели. Кстати одна из основных причин перехода на djbdns - это то, что bind требует слишком большое внимание к себе (необоснованно большое) - постоянные upgrade, постоянные проблемы с безопасностью и тд. (Это камень в огород вашей фразы о постоянном аудите серверов.)
<цитата>
а подобного рода поделки (djbdns) -- засуньте себе в сраку,
</цитата>
<цитата>я что-то пропустил ? DNS теперь принято перегружать раз в пять минут ?
</цитата>
Весь вопрос в масштабах. Если у вас один домен - то перезагрузка - не проблема. Если у вас тысячи доменов - то практически не проходит и дня, чтобы хотя бы в одном из доменов не поменялись данные. И в этм случае у djbdns преимущество за счет .cdb файла
На самом деле, флейм - отстой.
"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.
Так что если у кого-то оно час думает - ищите другую проблему...
<цитата>
Что тут известного? Схождение с ума? Не должно оно сходить с ума.
</цитата>
А оно и не сходит. Та ситуация. которую тут описали пусть останется
на совести авторов. Потому что 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 и его существующую поддержку в dns ввиде A6 от которого скорее всего откажутся. IPv6 скорее всего будет хоть не скоро, все к этому идет, а А6 скорее всего не будет, к этому тоже все идет, и поддержка сейчас А6 выглядит сомнительной и не нужной.
Кому нужно пожалуйста, пусть ставят себе что угодно и гоняют что угодно, но орать что А6 по зарез всем нужно и что это вообще суперфича, это тыкать пальцем в небо.
hrenvam.ru - не очень соответствует описанному случаю, надо с обращением к корневым серверам: XX1.myfirm при этом маздайкин софт не должен воспринимать днс-ответы - это типовой вариант с всевозможными глюкавыми виндовс-ускорителями. К сожалению единственный способ лечения - это не пускать таких юзеров к кэшу или возвращать ложные ответы или брать с ORSC _все_ домены первого уровня и никогда не отдавать юзерам ссылку на корневые сервера иначе каналу звездец. Ясно, что начиная с определенной конфигурации трудно понять где интернет снаружи или внутри узла ;)