Comments 62
новый, а тем более полезный опыт никогда не помешает =)
Ни для кого не секрет, что bind давно перестал быть стандартом de facto в мире dns серверов
По-моему, вы несколько преувеличиваете.
Возможно преувеличиваю, но лично у меня BIND вызывает только негативные эмоции. Как своим монстроидальным пожиранием ресурсов, так своим не простым синтаксисом конфигурационных файлов, а что самое главное — ужасно долгой перезагрузкой хоть сколько-нибудь серьезного количества зон.
> Ни для кого не секрет, что bind давно перестал быть стандартом de facto в мире dns серверов, как в качестве кеширущих, так и в качестве авторитетных для зон.
> В последнее время наибольшую популярность набирает разработка уважаемого господина D. J. Bernstein — djbdns
> Если перед Вами стоит задача настроить dns сервер — попробуйте djbdns, во всяком случае, как минимум Вы получите новый полезный опыт.
Ответственный DNS-сервер — это не тот объект, который ставят «по моде», это не графическая оболочка, не веб-браузер и не блог-сервис, в последнее время набирающий популярность. Если передо мной стоит задача настроить DNS-сервер — я буду настраивать стандарт де-факто, Berkeley Internet Name Database, а не «пробовать» и «экспериментировать» с веяниями моды.
А если я захочу поэкспериментировать — попробую и что-нибудь другое. Но не на продукционной системе, нет-нет.
> В последнее время наибольшую популярность набирает разработка уважаемого господина D. J. Bernstein — djbdns
> Если перед Вами стоит задача настроить dns сервер — попробуйте djbdns, во всяком случае, как минимум Вы получите новый полезный опыт.
Ответственный DNS-сервер — это не тот объект, который ставят «по моде», это не графическая оболочка, не веб-браузер и не блог-сервис, в последнее время набирающий популярность. Если передо мной стоит задача настроить DNS-сервер — я буду настраивать стандарт де-факто, Berkeley Internet Name Database, а не «пробовать» и «экспериментировать» с веяниями моды.
А если я захочу поэкспериментировать — попробую и что-нибудь другое. Но не на продукционной системе, нет-нет.
Поверьте, djbdns нормально справляется с работой в качестве кеширующего локального сервера, на mx серверах принимающих в день по паре миллионов коннектов. Время использования — несколько месяцев. За это время не было ни одной проблемы. Повторяюсь еще раз, Бернштейн — человек, которые делает _качественный_, _безопасный_, _производительный_ софт. Скорее всего в Вас говорит дань традиции, и то, что на протяжении нескольких десятилетий BIND был одним DNS сервером в репозитории Вашего дистрибутива. Времена изменились. Нет, серьезно, поверьте!
Бернштейн — человек, продукцией которого лучше не пользоваться.
Он гениален как программист, но никуда не годится как PM. Убедить его сделать что-то что не вписывается в его картину мира — нереально. Что будет если вам потребуется поддержка какого-нибудь протокола, который Бернштейн считает «идеологически неприавильным» (rfc 3007, к примеру). Будете костыли прикручивать?
Да, иногда преимущества его творений перевешивают недостатки и ими приходится пользоваться — но если есть выбор, то лучше что-нибудь другое. Скажем PowerDNS если вам под большую нагрузку… Они тоже умеют не всё, но, по крайней мере, они не навязывают вам ничего…
Он гениален как программист, но никуда не годится как PM. Убедить его сделать что-то что не вписывается в его картину мира — нереально. Что будет если вам потребуется поддержка какого-нибудь протокола, который Бернштейн считает «идеологически неприавильным» (rfc 3007, к примеру). Будете костыли прикручивать?
Да, иногда преимущества его творений перевешивают недостатки и ими приходится пользоваться — но если есть выбор, то лучше что-нибудь другое. Скажем PowerDNS если вам под большую нагрузку… Они тоже умеют не всё, но, по крайней мере, они не навязывают вам ничего…
Вы хотите сказать что qmail — плохой продукт? Или что он не популярен как MTA?
Я сказал то, что хотел сказать. Бернштейн создаёт интересные программы, но использовать их не нужно. И да, qmail — плохой продукт. На момент своего выхода это был хороший продукт, сейчас — нет. Он много вещей, которые требуются от соврменного MTA не умеет делать и популярность его падает. То же самое ожидает и djbdns.
Знаете, популярность sendmail всегда была большой, но это ни о чем не говорит.
Почему же. Говорит, конечно. В те времена когда популярность sendmail росла это действительно был лучший продукт. Сейчас она падает, так как качество этого зверя уже многих не удовлетворяет.
Качество продукта кореллирует не с его популярностью, а с ростом оной популярности. С первой производной. Так как уже установленные и налаженные системы никто перенастраивать не будет, а вот когда будут запускать новый сервер — тут будут делать выводы… и если продукт уж совсем плох — его сменят на что-то другое.
Качество продукта кореллирует не с его популярностью, а с ростом оной популярности. С первой производной. Так как уже установленные и налаженные системы никто перенастраивать не будет, а вот когда будут запускать новый сервер — тут будут делать выводы… и если продукт уж совсем плох — его сменят на что-то другое.
djbdns 50000 зон сколько по времени будет подгружать?
На какой машине?
Одно могу сказать точно, быстрее чем BIND:)
Хотя бы, потому что используется один файл для всех зон. А не много файлов для зон.
Одно могу сказать точно, быстрее чем BIND:)
Хотя бы, потому что используется один файл для всех зон. А не много файлов для зон.
UFO just landed and posted this here
Не уходите, никто Вас не заставляет.
Один файл в гигабайт будет читать намного быстрее чем несколько сотен тысяч файлов общим размером несколько гигабайт(да-да, у bind'a конфиги распухают гораздо быстрее!)
Вы бы взяли — и посмотрели на djbdns, хотя бы в качестве локального кеширующего сервера. Хотя бы посмотрите на потребление памяти:
ubique ~ # pmap -x 5087 | grep total
total kB 2880 — — — и
pmap 497 | grep -i total
Total Kb 13516 1636 936 1724
Лично мне 10 мегабайт на простой кеширующий сервер жалко.
Один файл в гигабайт будет читать намного быстрее чем несколько сотен тысяч файлов общим размером несколько гигабайт(да-да, у bind'a конфиги распухают гораздо быстрее!)
Вы бы взяли — и посмотрели на djbdns, хотя бы в качестве локального кеширующего сервера. Хотя бы посмотрите на потребление памяти:
ubique ~ # pmap -x 5087 | grep total
total kB 2880 — — — и
pmap 497 | grep -i total
Total Kb 13516 1636 936 1724
Лично мне 10 мегабайт на простой кеширующий сервер жалко.
Celeron 1,4
1G RAM
Если bind падает, то подымается он очень долго
1G RAM
Если bind падает, то подымается он очень долго
djbdns — очень удобная, стабильная и секьюрная штука. Пользуюсь ей в production уже много лет. Намного быстрее и надежнее бинда. Из недостатков — не совсем привычный (после бинда) конфиг, но освоив принцип, понимаешь, что так даже правильней.
Насчет безопасности и уверенности для установки на production:
Автор djbdns дает 1000 баксов каждому, кто найдет уязвимость в последней версии djbdns. Пока еще никто этих денег не получил. Кстати, последняя версия — ЕМНИП — датирована 11 февраля 2001 года.
Насчет безопасности и уверенности для установки на production:
Автор djbdns дает 1000 баксов каждому, кто найдет уязвимость в последней версии djbdns. Пока еще никто этих денег не получил. Кстати, последняя версия — ЕМНИП — датирована 11 февраля 2001 года.
История про вознаграждение за найденный бакс так же связана с qmail.
The qmail security guarantee
In March 1997, I offered $500 to the first person to publish a verifiable security hole in the latest version of qmail: for example, a way for a user to exploit qmail to take over another account.
The qmail security guarantee
In March 1997, I offered $500 to the first person to publish a verifiable security hole in the latest version of qmail: for example, a way for a user to exploit qmail to take over another account.
За найденный баг. Конечно же. Стоит сказать что за 11 лет никто ничего не нашел :)
На самом деле нашли:
secunia.com/advisories/10649/
www.frsirt.com/english/advisories/2005/0490
может и еще что-то было, уже не припомню.
Не знаю, правда, получил ли товарищ Guninski за них $500 или побрезговал связываться. Бернштейн — известный зануда и скандалист.
Насчет djbdns — когда я на него последний раз смотрел (2005 год), он произвел на меня отвратное впечатление:
1. dnscache и tinydns не могли работать на одном IP;
2. Вместо удобной функциональности views в BIND использовалось жалкое подобие левой руки — split horizon, которое к тому же не могло работать корректно при наличии только одного сетевого интерфейса;
3. Работа с отсылкой и обработкой NOTIFY выполнялась через какую-то очень большую задницу, чуть ли не с использованием левых скриптов на Перле, если не ошибаюсь;
4. Возможно, еще что-то, не могу вспомнить сейчас уже.
Не знаю, может, конечно, с тех пор что-то и улучшилось, но лично для меня он какой-то альтернативой BIND не является ни в малейшей степени.
secunia.com/advisories/10649/
www.frsirt.com/english/advisories/2005/0490
может и еще что-то было, уже не припомню.
Не знаю, правда, получил ли товарищ Guninski за них $500 или побрезговал связываться. Бернштейн — известный зануда и скандалист.
Насчет djbdns — когда я на него последний раз смотрел (2005 год), он произвел на меня отвратное впечатление:
1. dnscache и tinydns не могли работать на одном IP;
2. Вместо удобной функциональности views в BIND использовалось жалкое подобие левой руки — split horizon, которое к тому же не могло работать корректно при наличии только одного сетевого интерфейса;
3. Работа с отсылкой и обработкой NOTIFY выполнялась через какую-то очень большую задницу, чуть ли не с использованием левых скриптов на Перле, если не ошибаюсь;
4. Возможно, еще что-то, не могу вспомнить сейчас уже.
Не знаю, может, конечно, с тех пор что-то и улучшилось, но лично для меня он какой-то альтернативой BIND не является ни в малейшей степени.
Хорошо, пускай нашли один баг на 64 битной архитектуре. Но мне кажется что это не сравниться с количеством багов в sendmail? Или я не прав?
1. Вам жалко еще одного ip адреса?
2. Не при наличии одного сетевого интерфейса, а при наличии одного ip на интерфейсе. Согласен что возможно это не правильно, но 13 метров памяти для кеширующего сервера ничем не лучше.
3. djbdns и bind не могут использовать notify из-за бажной реализации notify в bind.
1. Вам жалко еще одного ip адреса?
2. Не при наличии одного сетевого интерфейса, а при наличии одного ip на интерфейсе. Согласен что возможно это не правильно, но 13 метров памяти для кеширующего сервера ничем не лучше.
3. djbdns и bind не могут использовать notify из-за бажной реализации notify в bind.
Из приведенных мной двух багов только один связан с 64-битной архитектурой. Второй — про buffer overflow при передаче больших писем (больше 2G). Насчет «вам жалко» — это, знаете ли, жалкий аргумент. Просто djbdns не умеет этого, если такая функциональность нужна, значит, djbdns придется выкинуть и использовать bind. С NOTIFY же в BIND все в порядке (вы, видимо, перепутали с некорректной реализацией AXFR в BIND 9 до какой-то там версии), просто tinydns принципиально не умеет их ни посылать, ни обрабатывать (хотя в лог об их приходе исправно пишет, и workaround как раз и заключался в том, что периодически по крону запускается скрипт на Перле, который ищет эти записи и запускает tcpclient для их стягивания с master'ов).
За письма размером 2 GB — нужно убивать.
Да, с axfr перепутал.
Да, с axfr перепутал.
Баг, насколько я помню, не подтвердился. Как обычно — шум подняли, а бага нету. Так что с 2001 года никто его не ломал. Но не в этом суть — софт работает. И работает отлично, для меня это самое главное.
Но конечно, надо учитывать его недостаток — софт так же нестандартен как и его автор :)
Но конечно, надо учитывать его недостаток — софт так же нестандартен как и его автор :)
Какой из багов? К примеру, про integer overflows в 64-битном qmail Берштейн сказал, что, мол, «No real-world deployment of qmail would be susceptible» и «Fortunately, counter growth was limited by memory and thus by configuration, but this was pure luck». При этом требования для эксплоита — всего-то 64-битная машина и >4G виртуальной памяти на процесс — не такие уж и невероятные по нынешним временам. Кстати, выпускать патч для этих overflows он и не спешит (типа, лимиты нас спасут) — ну, это уже чисто из упрямства.
Насчет «нестандартности» софта — отдельный разговор. Не надо забывать, что автор — университетский профессор, пишет софт для обучения студентов, и годится этот софт, соответственно, только для обучения студентов. Для того, чтобы его в реальном мире использовать, к нему надо присандалить костылей столько, что дырки, находимые в этих костылях, с успехом перекрывают по опасности дырки в софте, который можно было бы использовать вместо софта Бернштейна. Скажем, некорректно написанный самопальный перловый скрипт для обработки NOTIFY вполне способен помочь удаленному злоумышленнику сделать hijack любой slave зоны на твоем djbdns.
Насчет «нестандартности» софта — отдельный разговор. Не надо забывать, что автор — университетский профессор, пишет софт для обучения студентов, и годится этот софт, соответственно, только для обучения студентов. Для того, чтобы его в реальном мире использовать, к нему надо присандалить костылей столько, что дырки, находимые в этих костылях, с успехом перекрывают по опасности дырки в софте, который можно было бы использовать вместо софта Бернштейна. Скажем, некорректно написанный самопальный перловый скрипт для обработки NOTIFY вполне способен помочь удаленному злоумышленнику сделать hijack любой slave зоны на твоем djbdns.
Откуда у Вас столько уверенности, что софт этот не пригоден для продакшна? Еще раз спрашиваю про qmail — Вы статистику используемых MTA видели? Если есть там qmail — значит он _работает_. Более того, если его используют более менее крупные ISP/хостеры это говорит о том, что qmail работает хорошо. Вам показать список уязвимостей в BIND? Пожалуйста, попробуйте перестать занимать позицию «BIND и только BIND», попробуйте занять позицию «BIND и с некоторыми оговорками другие сервера». Право, это умнее!
Это вы утверждаете, что «ни для кого не секрет, что bind давно перестал быть стандартом de facto в мире dns серверов» и «в последнее время наибольшую популярность набирает разработка уважаемого господина D. J. Bernstein — djbdns». И первое, и второе — ложь: bind по-прежнему является reference implementation DNS-сервера, а djbdns не является «наиболее популярным» DNS-сервером, и не способен им стать в обозримом будущем из-за кучи болячек генетического происхождения. Так что занять позицию «BIND и с некоторыми оговорками другие сервера» вам, действительно, было бы умнее.
Вы подменяете понятия. «в последнее время наибольшую популярность набирает разработка уважаемого господина D. J. Bernstein — djbdns» отнюдь не значит, что djbdns — «наиболее популярным». Перечитайте внимательно исходный пост и поймите наконец, что я считаю djbdns новым стандартом dns серверов. Если Вы до сих пор не поняли, то я хотел донести до широкой общественности, что существует хорошая альтернатива BIND, использование которой в некоторых случаях лучше чем использование BIND. Перечитайте мои комментарии, я нигде не говорил, что следует немедленно прекратить использовать BIND. Вы же, занимаете позицию, что djbdns ни в коем случае не стоит использовать даже для локального кеширующего сервера, то есть позицию «BIND и только BIND». Я понял Вашу точку зрения. На сим предлагаю Вам прекратить наш спор, ибо каждый останется при своем мнении, а дальнейшие споры, выяснение отношений мне никак не хочется здесь лицезреть. Спасибо.
> Хорошо, пускай нашли один баг на 64 битной архитектуре. Но мне кажется что это не сравниться с количеством багов в sendmail? Или я не прав?
Может их просто ищет намного меньше людей, чем иих ищут в sendmail
Может их просто ищет намного меньше людей, чем иих ищут в sendmail
а функционал тот же что и в бинде?
гибкость настроек? различные настройки для разных view?
есть аналог nsupdate?
гибкость настроек? различные настройки для разных view?
есть аналог nsupdate?
Функционал достаточно богат, но есть вещи, которые Бернштейн категорически отказывается поддерживать. Скажем AAAA записи или RFC3007. Не потому что их сложно поддержать, а потому что они, типа, идеологически неправильны.
Мой принцип: с религиозными фанатиками не связываться, а Бернштейн — один из них. Не так давно DJBDNS стал свободным ПО (в декабре прошлого года), может быть кто-нибудь и озаботится тем, чтобы сделать из него что-то вменяемое. Но так как сам автор его забросил, то…
В общем не советую я вам с ним связываться.
Мой принцип: с религиозными фанатиками не связываться, а Бернштейн — один из них. Не так давно DJBDNS стал свободным ПО (в декабре прошлого года), может быть кто-нибудь и озаботится тем, чтобы сделать из него что-то вменяемое. Но так как сам автор его забросил, то…
В общем не советую я вам с ним связываться.
views — к сожалению нет.
AXFR поддерживается.
Посмотрите вот это сравнение bind и djbdns: cr.yp.to/djbdns/blurb/easeofuse.html
AXFR поддерживается.
Посмотрите вот это сравнение bind и djbdns: cr.yp.to/djbdns/blurb/easeofuse.html
значит бинд и останется стандартом.
djbdns конечно хороший сервер, но только как облегченный вариант бинда.
djbdns конечно хороший сервер, но только как облегченный вариант бинда.
Поймите, я не говорю что djbdns становится новым стандартом dns сервером. Я лишь говорю, что это очень хорошая альтернатива bind. Если для Вас основным критерием в выборе DNS сервера является наличие поддержки views — то, да — Вам нужен BIND. Но по моему личному опыту могу сказать — что views мне не потребовался ни разу. Да если бы и потребовался — ничто не мешает мне запустить пару djbdns в jail'ах, слушающих разные интерфейсы и отдающие различные данные. Не будьте зацикленными на bind, попробуйте djbdns, думаю Вам понравится:)
есть ряд функций нужных в днс сервере — view, tsig и иногда round robin.
в тоже время на локальный компьютер djbdns я поставил и как простой и маленький днс он вполне приемлим
в тоже время на локальный компьютер djbdns я поставил и как простой и маленький днс он вполне приемлим
Вы round robin для load balancing используете? Давно доказано, что это самый худший варант балансировки, которые толком-то не балансирует.
Ответ Бернштейна по поводу tsig:
Brad Knowles, 2002.03.25: ``There aren't even any patches that can get djbdns to implement TSIG, Dynamic DNS, or DNSSEC, nor are they ever likely to be created (my understanding is that the author is strongly opposed to them).''
Brad Knowles, 2002.11.09: ``[djbdns] does not, and author's code will not, support new DNS features: DNSSEC, TSIG, IXFR, NOTIFY, EDNS0, IPv6, etc...''
Facts: IPSEC provides better security than TSIG. IPSEC is inherently easier to set up than TSIG: it has the big advantage of applying to all protocols, rather than being glued into the guts of one protocol. There are, similarly, superior alternatives to the DNS update protocol, IXFR, and NOTIFY.
EDNS0 currently doesn't accomplish anything. I'm not strongly opposed to it; there simply isn't any benefit for the users.
DNSSEC currently doesn't accomplish anything, even though it is falsely advertised as preventing forgeries. I'm not strongly opposed to it; there simply isn't any benefit for the users.
Можно узнать где реально Вы применяете указанный Вами функционал bind?
Ответ Бернштейна по поводу tsig:
Brad Knowles, 2002.03.25: ``There aren't even any patches that can get djbdns to implement TSIG, Dynamic DNS, or DNSSEC, nor are they ever likely to be created (my understanding is that the author is strongly opposed to them).''
Brad Knowles, 2002.11.09: ``[djbdns] does not, and author's code will not, support new DNS features: DNSSEC, TSIG, IXFR, NOTIFY, EDNS0, IPv6, etc...''
Facts: IPSEC provides better security than TSIG. IPSEC is inherently easier to set up than TSIG: it has the big advantage of applying to all protocols, rather than being glued into the guts of one protocol. There are, similarly, superior alternatives to the DNS update protocol, IXFR, and NOTIFY.
EDNS0 currently doesn't accomplish anything. I'm not strongly opposed to it; there simply isn't any benefit for the users.
DNSSEC currently doesn't accomplish anything, even though it is falsely advertised as preventing forgeries. I'm not strongly opposed to it; there simply isn't any benefit for the users.
Можно узнать где реально Вы применяете указанный Вами функционал bind?
>Давно доказано, что это самый худший варант балансировки,
> которые толком-то не балансирует.
А можно немного подробнее? Кем, как доказано?
> которые толком-то не балансирует.
А можно немного подробнее? Кем, как доказано?
Для начала здесь:
en.wikipedia.org/wiki/Round_robin_DNS
секция drawback
В основном проблема в том, что записи будут оседать в cache крупных провайдеров
en.wikipedia.org/wiki/Round_robin_DNS
секция drawback
В основном проблема в том, что записи будут оседать в cache крупных провайдеров
view — перенаправление разных пользователей по географическому местоположению на разные сервера.
tsig — наверно и так понятно — увеличение секурности
round robin — для примера приведен — не пользую ( вьюшки полность его заменяют)
tsig — наверно и так понятно — увеличение секурности
round robin — для примера приведен — не пользую ( вьюшки полность его заменяют)
Почему то мне кажется, что Вы ни первое, ни второе, ни третье ни разу не использовали, более того, использовать и не будете. Простите, если я не прав.
прощаю :)
с чего интересно вы это взяли?
с чего интересно вы это взяли?
Вы, конечно, извините, но для больших проектов подобное использование — не редкость. А на малых и BIND отлично с нагрузками справляется. Ну и нафига козе баян? В смысле djbdns?
Я имел ввиду, что для _действительно_ больших проектов, в которых стоит думать о load balancing'е на уровне geo position, в качесте DNS серверов вряд ли будет использоваться BIND ;) Собственно скорее всего как и djbdns.
И ровным счетом ничего больше.
И ровным счетом ничего больше.
Ой ли? Отключите в BIND'е рекурсию — и он справится с весьма и весьма изрядной нагрузкой. И вам не нужно будет чесать правое ухо левой ногой.
Я не собираюсь говорить что BIND — идеал. Вовсе нет. Но djbdns альтернативой BIND'у не является ни разу. Просто из-за идиотской позиции автора по куче вопросов.
Я не собираюсь говорить что BIND — идеал. Вовсе нет. Но djbdns альтернативой BIND'у не является ни разу. Просто из-за идиотской позиции автора по куче вопросов.
Я не говорю о производительности в плане способности обратотать n запросов в секунду. Для меня более приоритетным является время обновления нескольких десятков тысяч зон.
И по поводу количества обрабатываемых запросов. Чтобы не быть голословными — посмотрите на www.faqts.com/knowledge_base/view.phtml/aid/11438/fid/699. Из-за этой же идиотской позиции автора его софт работает быстро и надежно, ничего более.
И по поводу количества обрабатываемых запросов. Чтобы не быть голословными — посмотрите на www.faqts.com/knowledge_base/view.phtml/aid/11438/fid/699. Из-за этой же идиотской позиции автора его софт работает быстро и надежно, ничего более.
Для меня более приоритетным является время обновления нескольких десятков тысяч зон.У вас эти зоны каждую секунду меняются? Если BIND берёт данные из LDAP, то ничего перезапускать и перечитывать не нужно.
Чтобы не быть голословными — посмотрите на www.faqts.com/knowledge_base/view.phtml/aid/11438/fid/699.Мы вроде про djbdns говорим? При чём тут dnscache? Да, рекурсивный BIND — не самая прекрасная штука, но для этих целей есть другие сервера.
Каждый час происходит перегенарация. Поверьте, 25 % часа на чтение зон — много. Слишком.
Да, говорим мы про djbdns, и если и Вы потрудитесь внимательно все перечитать, то я нигде не говорил об исключительном использовании оного как авторитетного dns сервера. Я говорю о всех его возможностях. Если Вы не знаете, то djdbns это грубо говоря набор различных программ. И еще, если Вы уж используете ipv6, то наверное должны знать что CIDR не применяется в ipv6 и указывать ipv6 сеть через cidr нотацию, по крайней мере странно.
Да, говорим мы про djbdns, и если и Вы потрудитесь внимательно все перечитать, то я нигде не говорил об исключительном использовании оного как авторитетного dns сервера. Я говорю о всех его возможностях. Если Вы не знаете, то djdbns это грубо говоря набор различных программ. И еще, если Вы уж используете ipv6, то наверное должны знать что CIDR не применяется в ipv6 и указывать ipv6 сеть через cidr нотацию, по крайней мере странно.
а может для перегенерации и стоит использовать nsupdate?
мой внутренний голос говорит что обновление зон может вполне происходить в ту секунду как она изменится (на мастер сервере).
мой внутренний голос говорит что обновление зон может вполне происходить в ту секунду как она изменится (на мастер сервере).
Я прекрасно понимаю как можно ускорить обновление зон для BIND. Но в ввиду определенных условий, сделав так как Вы предлагаете, у меня возрастет нагрузка на базу. Скажем так, в виду архитектурной особенности сделать nsupdate для каждой меняющейся зоны нельзя.
Sign up to leave a comment.
djbdns