В статье "Setting up a BIND DLZ Nameserver with MySQL Replication (http://www.zazzybob.com/bind_dlz.html)" представлен пример настройки DNS сервера, распределенного для повышения надежности на несколько серверов, через хранение данных в MySQL с применением репликации данных.
Для хранения данных в БД используется патч bind-dlz (http://bind-dlz.sourceforge.net/), обеспечивающий поддержку БД
Berkeley DB, PostgreSQL, MySQL ODBC (thus Firebird, DB2, Oracle, Sybase, SAPDB) или LDAP. Следует заметить, что при использовании bind-dlz сильно понижается (http://bind-dlz.sourceforge.net/perf_tests.html) производительность, по сравнению с оригинальным bind.
URL: http://www.zazzybob.com/bind_dlz.html
Новость: http://www.opennet.ru/opennews/art.shtml?num=13254
нуу и зачем оно нужно ? надёжность ?
Для руления очень большими зонами. А то знаете BIND их в памяти хранит. Хотя лучше для этого заюзать PowerDNS. Он лучше с базами работает.
Например для хостингов, позволить через веб фигачить клиентам свои зонны. Вообще кашерней в базе инфу хранить.
при большом кол-ве зон, на мощном железе можно уступить производительность в обмен на управляемость.
кстати в FreeBSD 6.3-PRE уже из коробки этот функционал, не в курсе либо в 9,4 бинд это втянули, либо патчат руками.в любом случае, на хомяке авторов dlz данные о производительности неубедительны, хотя может уже поправили.
>кстати в FreeBSD 6.3-PRE уже из коробки этот функционал, не в курсе
>либо в 9,4 бинд это втянули, либо патчат руками.шо, серьезно? пошел обновляться :)
На мой взгляд вещь без смыла :(
rndc с ключами для руления ни кто не отменял.
Память дешевая. Не могу представить размера базы, что бы надо было это хранить в СУБД.
>На мой взгляд вещь без смыла :(
>rndc с ключами для руления ни кто не отменял.
>Память дешевая. Не могу представить размера базы, что бы надо было это
>хранить в СУБД.а зря.
mysql> select count(*) from records;
+----------+
| count(*) |
+----------+
| 5790753 |
+----------+
1 row in set (3 min 19.16 sec)
>[оверквотинг удален]
>>хранить в СУБД.
>
>а зря.
>mysql> select count(*) from records;
>+----------+
>| count(*) |
>+----------+
>| 5790753 |
>+----------+
>1 row in set (3 min 19.16 sec)а еще на этой базе ваш любимый rndc тупо валится по таймауту.
>[оверквотинг удален]
>>mysql> select count(*) from records;
>>+----------+
>>| count(*) |
>>+----------+
>>| 5790753 |
>>+----------+
>>1 row in set (3 min 19.16 sec)
>
>а еще на этой базе ваш любимый rndc тупо валится по таймауту.
>Если Вы ведете корневой DNS это другой разговор.
Но иначе, если у Вас в зарегистрировано 5790753 записей в DNS, надо понять для чего такой номер может вообще понадобиться.
Извините но представить вменяемую конфигурация для которой может понадобиться такое кол-во записей - мягко говоря сложно :(
>Извините но представить вменяемую конфигурация для которой может понадобиться такое кол-во записей
>- мягко говоря сложно :(развивайте воображение :)
локальный RBL некрупного релея.
>>Извините но представить вменяемую конфигурация для которой может понадобиться такое кол-во записей
>>- мягко говоря сложно :(
>
>развивайте воображение :)
>локальный RBL некрупного релея.Ну хорошо, если для локального - то зачем пихать это хозяйство в DNS....
Есть более простые и более производительные способы. Как вариант складывать в файл и блокировать (выборка grep'ом):)Если же мы делаем открытый RBL там возможно такое и нужно,
хотя если я делал бы - наверно выбрал другой путь (надо подумать но в базу пихать бы не стал).По поводу спама вообще - RBL для меня не применимо, и (мое личное мнение!) это баловство.
т.к. машины к-е рассылают спам, как правило являются зараженными и т.о. в блокировку попадают целые организации.
Мне лично по душе пришелся SPF работает достаточно надежно, да не все его сейчас поддерживают но я думаю это вопрос времени.
И не мешало бы провайдерам всяких ADSL отказаться от прописывания реверсной зоны, а по RFC почтовик обязан иметь реверсную зону, как вариант проверять и это.
А вот в случае больших пулов и возникают громадные базы адресов.А как только человек поймал вируса - его в топку, ну на мой взгляд это не совсем правильно. А если он вылечился. :)
PS: Если делать по уму глупостей можно и избежать. (Это мое личное мнение не претендующее на истину в последней инстанции.)
т.е. 3минуты 19секунд база лежала? :)
>т.е. 3минуты 19секунд база лежала? :)это откуда вывод что mysql на select count(*) ложит базу??
>>т.е. 3минуты 19секунд база лежала? :)
>
>это откуда вывод что mysql на select count(*) ложит базу??от незнания
count(*) по несчасным 5 лимонам строк шел ____ТРИ____ минуты! В топку мыскль!
Простите, а у вас mysql не на pentium 133 mhz 32 ram работает?select count(*) from tables;
Запрос занял 0.0003 сек
count(*)
23519676
>> представлен пример настройки DNS сервера, распределенного для повышения надежности на несколько серверов, через хранение данных в MySQL с применением репликации данных.Звучит достаточно идиотично в свете наличия в DNS своей AXFR/IXFR. bind в своей нише замечательно справляется с возложенными на него задачами, если требуется что-то большее то powerdns вполне подойдет.
Ерунда полная
Да, данные надо хранить в базе, и управлять ими в базе
Но ещё и работать напрямую с базой - увольте
Никакой секурности, надежности, и производительности.
Может апачу сразу виртхосты из базы брать, и sshd в mysql лезть за паролем акка?
У каждого приложения свой формат данных, обезспечивающий нужную функциональность и прозводительность, надо всего-навсего писать фильтры, который из данных в базе будут генерить конфиги для приложений.
>Может апачу сразу виртхосты из базы брать, и sshd в mysql лезть
>за паролем акка?за этим к libnss-mysql :)
>Ерунда полная
>Да, данные надо хранить в базе, и управлять ими в базе
>Но ещё и работать напрямую с базой - увольте
>Никакой секурности, надежности, и производительности.Это вы разработчикам ldap скажите.
>Это вы разработчикам ldap скажите.Не поверите, это они и говорят :) - не используйте SQL backend для праймори.
>Ерунда полная
>Да, данные надо хранить в базе, и управлять ими в базе
>Но ещё и работать напрямую с базой - увольте
>Никакой секурности, надежности, и производительности.
>Может апачу сразу виртхосты из базы брать, и sshd в mysql лезть
>за паролем акка?PAM хорошая штука, уважаемый, и тоже имеет право на жизнь.
Не надо вешать ярлыки.
Пока не нашли устраивающего всех баланса секурности, надёжности, производительности и удобства. Если бы не пидорги-параноики поломавшие SMTP, может он так Simple и остался бы всем на радость.
Типичное юношеское увлечение. Чего только не хранят в mysql! Два десятка учетных записей, файл hosts, а теперь и зоны DNS.Бред это! База данных типа mysql прежде всего заточена под оптимальное обслуживание интенсивных запросов чтения - записи в равных пропорциях. У любого DNS сервера соотношение запросов чтения к транзакциям записи, наверное, 999 к 1. Именно по этому BIND хранит зоны в памяти, а обновляет их пинком rndc. Люди, писавшие сей патч - может они и программисты (в смысле, знают С), но это очень ГЛУПЫЕ программисты.
>Типичное юношеское увлечение. Чего только не хранят в mysql! Два десятка учетных
>записей, файл hosts, а теперь и зоны DNS.
>
>Бред это! База данных типа mysql прежде всего заточена под оптимальное обслуживание
>интенсивных запросов чтения - записи в равных пропорциях.Это кто вам такую глупость сказал?
Покажите мне, например, где на http://dev.mysql.com/doc/refman/5.1/en/introduction.html это написано?для сравнения кэши запросов:
Cache hitrate, 1, 5, 10 minute averages: 4.2%, 7.5%, 9.1%
Backend query cache hitrate, 1, 5, 10 minute averages: 57%, 57%, 57%
>Бред это! База данных типа mysql прежде всего заточена под оптимальное обслуживание
>интенсивных запросов чтения - записи в равных пропорциях.MySQL как раз на чтение заточена и очень редкую запись :-) При интенсивной записи, табличные блокировки в MyISAM убивают производительность.
Bind-dlz оправданная штука, только кэширования нормального не хватает, типа интегрированного memcached с возможностью задания таймаута для записей в базе.
Мне PowerDNS очень уж нравится, сейчас зона на 3000 записей - хавает 6 метров оперативы и не грузит камень.
База юзается - sqlite...
Можно бинд спрятать за кешируюищим сервером, чтобы основную нагрузку по отдаче воспринимал последний, а бинд будет просто из базы брать и отдавать при cache miss.
Честно говоря, с трудом себе представляю эту картину. Особенно если учитывать, что BIND грузится гораздо раньше MySQL.
>Честно говоря, с трудом себе представляю эту картину.а чего там представлять? поставь и посмотри в действии, благо времени отнимает немного
>Особенно если учитывать, что
>BIND грузится гораздо раньше MySQL.это тут каким боком?
во фряшных портах этот патч давно
использование вполне конкретное - для авторитетного сервера с кучей зон
понятия первичный и вторичный неуместно, синхронизация зон происходит за счёт репликации mysql
такой сервер очень удобно использовать с какой-либо хостинговой панелью, можно легко отдать контроль за доменом пользователю
+1
Вообще хорошая штука но я так и не понял поддерживает ли он отсылку уведомлений об изменениях зоны другим серверам, на которых не стоит bind-dlz