Комментарии 29
Небольшой вопрос.
Зачем переписывать с перла на питон, если оно и так работает? Дань моде?
Зачем переписывать с перла на питон, если оно и так работает? Дань моде?
скорее дань юзабилити
1-я заповедь программиста: Работает — не трогай.
и только потом 2-я — рефакторинг (читай переписывание на модных языках)
и только потом 2-я — рефакторинг (читай переписывание на модных языках)
1-я заповедь программиста: Работает — не трогай.
и только потом 2-я — рефакторинг (читай переписывание на модных языках)
и только потом 2-я — рефакторинг (читай переписывание на модных языках)
Критерии юзабельности ЯП для каждого человека разные, и каждый сам выбирает себе инструмент. Да и правило — «короче тот путь, который знаешь» — никто не отменял. Например для меня перл лучше, т.к. я его лучше знаю.
А вот автор вроде бы и перл неплохо знает. Поэтому мне и стало интересно.
А вот автор вроде бы и перл неплохо знает. Поэтому мне и стало интересно.
сорри, это сюда habrahabr.ru/blogs/s_admin/111678/#comment_4249166
почему бы просто не использовать powerdns или аналоги, напрямую работающие с базой?
Если Вам обязательно надо часто менять данные в зонах то может стоить подумать о том чтоб собрать bind с поддержкой mysql\ldap\postgres\… на выбор
тогда обновление будет сводится только к обновлению записей в таблице и будет применяться без перезапуска самого bind-a
тогда обновление будет сводится только к обновлению записей в таблице и будет применяться без перезапуска самого bind-a
Это костыль, и он довольно-таки кривой. Кривости следующие:
1. На один запрос к ДНС получается несколько запросов к базе, почему — черт знает;
2. Нельзя реализовать принцип master-slave, BIND не умеет выгружать зону из базы;
3. Из-за пункта 2 надо всем серверам давать доступ к базе вместо того чтобы пользоваться AXFR/IXFR;
4. Из-за пункта 3 вместо нескольких независимых DNS серверов, каждый из которых при недоступности мастера будет отвечать на запросы к зоне еще в течение expire периода, получаем несколько серверов завязанных на одну базу данных.
1. На один запрос к ДНС получается несколько запросов к базе, почему — черт знает;
2. Нельзя реализовать принцип master-slave, BIND не умеет выгружать зону из базы;
3. Из-за пункта 2 надо всем серверам давать доступ к базе вместо того чтобы пользоваться AXFR/IXFR;
4. Из-за пункта 3 вместо нескольких независимых DNS серверов, каждый из которых при недоступности мастера будет отвечать на запросы к зоне еще в течение expire периода, получаем несколько серверов завязанных на одну базу данных.
3, 4: можно реализовать master-slave на уровне БД MySQL.
Это Вы про DLZ говорите? Отлично работает связка из мастера с DLZ и слейвов без него, с помощью тех самых AXFR/IXFR. Хотя таки да, рекомендуют они использовать репликацию БД, так данные попадают на слейвы быстрее.
Примеры можете глянуть например на официальном сайте расширения: «If you must support zone transfers with DLZ, use the configuration below …»
Примеры можете глянуть например на официальном сайте расширения: «If you must support zone transfers with DLZ, use the configuration below …»
AXFR — да, можно сделать, однако на том же сайте можно прочитать:
While this method of data replication is necessary when not using DLZ, and is in fact the «standard» way (according to the RFC's) of propogating data, it is not how data replication should be handled with DLZ.
Про IXFR:
zone tranfers with DLZ require a full zone transfer — resulting in a lot of wasted data being sent across the wire.
То есть перекачивается вся зона вместо небольшого числа записей, плюс перекачивается она при наступлении expire. В общем, не самое удачное решение. Если нужна база, лучше генерить зоны из нее чем-то внешним, а распространение отдать на откуп DNS'ам, они справятся лучше.
И да, IXFR можно тоже сделать, но схема получается настолько «via anus», что я ее даже врагу не пожелаю.
While this method of data replication is necessary when not using DLZ, and is in fact the «standard» way (according to the RFC's) of propogating data, it is not how data replication should be handled with DLZ.
Про IXFR:
zone tranfers with DLZ require a full zone transfer — resulting in a lot of wasted data being sent across the wire.
То есть перекачивается вся зона вместо небольшого числа записей, плюс перекачивается она при наступлении expire. В общем, не самое удачное решение. Если нужна база, лучше генерить зоны из нее чем-то внешним, а распространение отдать на откуп DNS'ам, они справятся лучше.
И да, IXFR можно тоже сделать, но схема получается настолько «via anus», что я ее даже врагу не пожелаю.
1. Когда писал нейтивний драйвер под СУБД Firebird чето не заметил чтоб он по нескольку раз делал запросы. Найду свои старые коды — посмотрю.
2,3,4 — уже люди уже ответили
2,3,4 — уже люди уже ответили
В смопнил.
1. Значит там по каждому ДНС запросу идет 2 запроса БД — 1 для определения того можно ли отдать запрашиваемому клиенту ответ, 2 — сам ответ.(аналоги allow-query allow-transfer)
1. Значит там по каждому ДНС запросу идет 2 запроса БД — 1 для определения того можно ли отдать запрашиваемому клиенту ответ, 2 — сам ответ.(аналоги allow-query allow-transfer)
Не совсем понятна цель. На cpan.org огромное кол-во модулей для чтения, парсинга и написания DNS зон, а уж увязать это с базой проблем вообще никаких. Впрочем, свой велосипед — это всегда интересно.
А почему не используете rndc чтобы перечитать конфиг/перегрузить зоны BIND'а без его рестарта? Насколько я понимаю, много мелких зон, в этом случае BIND довольно долго стартует, ISC только в последних версиях ускорили этот процесс.
А почему не используете rndc чтобы перечитать конфиг/перегрузить зоны BIND'а без его рестарта? Насколько я понимаю, много мелких зон, в этом случае BIND довольно долго стартует, ISC только в последних версиях ускорили этот процесс.
Практически две сотни зон и рестарт занимает менее полсекунды. Оно изначально так было, я не трогал. Спасибо за идею с rndc. Попробую. Правда не уверен, что сильно скажется на производительности.
Кстати, ISC недавно исправило недавний же баг. Суть была такова: при старте BIND запускается одновременно N зон, после них ещё N и так далее, пока все не запустятся. Баг был, что N было маленьким, что-то вроде 10, вместо тысяч. Так что я бы не говорил, что только в последних версиях исправили. В BIND 9.4 такого точно нет.
Для таких вещей есть PowerDNS.
bind — это, по сути, reference design.
bind — это, по сути, reference design.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Система автоматической генерации настроек DNS-сервера Bind