Открыть список
Как стать автором
Обновить

Комментарии 29

Небольшой вопрос.
Зачем переписывать с перла на питон, если оно и так работает? Дань моде?
скорее дань юзабилити
1-я заповедь программиста: Работает — не трогай.
и только потом 2-я — рефакторинг (читай переписывание на модных языках)
1-я заповедь программиста: Работает — не трогай.
и только потом 2-я — рефакторинг (читай переписывание на модных языках)
звиняйте за дубляж. чето сайт заглючил
Я бы сказал это 1ая заповедь ленивого человека, если есть интерес переписать и есть свободное время — надо переписать. Единственно что уже годами проверено, это нельзя в пятницу ставить апдейты и вообще лучше ничего не трогать на продакшне.
Для мены какраз пятница\суббота пора адпейтов. Ибо тогда мало людей работают и никто плешь не ест (у меня оплаты а у меня заявки, а когда будет и т.д. и т.п.)
Критерии юзабельности ЯП для каждого человека разные, и каждый сам выбирает себе инструмент. Да и правило — «короче тот путь, который знаешь» — никто не отменял. Например для меня перл лучше, т.к. я его лучше знаю.
А вот автор вроде бы и перл неплохо знает. Поэтому мне и стало интересно.
почему бы просто не использовать powerdns или аналоги, напрямую работающие с базой?
Подскажите пожалуйста какие еще есть DNS сервера, которые нативно работают с БД, кроме PowerDNS.
Если Вам обязательно надо часто менять данные в зонах то может стоить подумать о том чтоб собрать bind с поддержкой mysql\ldap\postgres\… на выбор
тогда обновление будет сводится только к обновлению записей в таблице и будет применяться без перезапуска самого bind-a
Это костыль, и он довольно-таки кривой. Кривости следующие:
1. На один запрос к ДНС получается несколько запросов к базе, почему — черт знает;
2. Нельзя реализовать принцип master-slave, BIND не умеет выгружать зону из базы;
3. Из-за пункта 2 надо всем серверам давать доступ к базе вместо того чтобы пользоваться AXFR/IXFR;
4. Из-за пункта 3 вместо нескольких независимых DNS серверов, каждый из которых при недоступности мастера будет отвечать на запросы к зоне еще в течение expire периода, получаем несколько серверов завязанных на одну базу данных.
3, 4: можно реализовать master-slave на уровне БД MySQL.
Можно, но зачем, если у DNS сервера есть вполне себе неплохо работающие механизмы?
Я просто предложил вариант решения задачи. Если нужно настроить DNS-сервер с MySQL — я буду использовать репликацию БД. Это нагляднее и быстрее. Когда нужно использовать голый Bind — я буду раздавать зоны по 53/TCP.
Это Вы про DLZ говорите? Отлично работает связка из мастера с DLZ и слейвов без него, с помощью тех самых AXFR/IXFR. Хотя таки да, рекомендуют они использовать репликацию БД, так данные попадают на слейвы быстрее.

Примеры можете глянуть например на официальном сайте расширения: «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», что я ее даже врагу не пожелаю.
1. Когда писал нейтивний драйвер под СУБД Firebird чето не заметил чтоб он по нескольку раз делал запросы. Найду свои старые коды — посмотрю.
2,3,4 — уже люди уже ответили
В смопнил.
1. Значит там по каждому ДНС запросу идет 2 запроса БД — 1 для определения того можно ли отдать запрашиваемому клиенту ответ, 2 — сам ответ.(аналоги allow-query allow-transfer)
Хм, у нас гражданин переписывал для Oracle, там у него выходило по четыре-пять запросов.
Жаль код посеял (был на виртуалке Virtual PC) а потом во времена дисковой недостачи снес его
Не совсем понятна цель. На cpan.org огромное кол-во модулей для чтения, парсинга и написания DNS зон, а уж увязать это с базой проблем вообще никаких. Впрочем, свой велосипед — это всегда интересно.
А почему не используете rndc чтобы перечитать конфиг/перегрузить зоны BIND'а без его рестарта? Насколько я понимаю, много мелких зон, в этом случае BIND довольно долго стартует, ISC только в последних версиях ускорили этот процесс.
Практически две сотни зон и рестарт занимает менее полсекунды. Оно изначально так было, я не трогал. Спасибо за идею с rndc. Попробую. Правда не уверен, что сильно скажется на производительности.
А, две сотни зон — это действительно не страшно, заметно будет на десятках тысяч.
Кстати, ISC недавно исправило недавний же баг. Суть была такова: при старте BIND запускается одновременно N зон, после них ещё N и так далее, пока все не запустятся. Баг был, что N было маленьким, что-то вроде 10, вместо тысяч. Так что я бы не говорил, что только в последних версиях исправили. В BIND 9.4 такого точно нет.
Я говорил про десятки тысяч зон. На одном сервере пришлось вытесать костыль чтобы как раз BIND 9.4 запускался после sshd, иначе во время его старта (~70-80k зон) на сервер было не попасть.
Понятно. Действительно, у меня масштабы не те.
Для таких вещей есть PowerDNS.
bind — это, по сути, reference design.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.