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

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

А редактировать как?
Любым mysql-клиентом. Я вот phpMyAdmin использую.
А BIND при работе с dlz кеширует запросы? Или на каждый запрос в базу лезет?
Нет, не кеширует. В FAQ есть ответ почему.

Если вкратце, DLZ создан для динамической загрузки зон. Вводя кеширование мы вносит задержку равную времени валидности кешированных данных
Я по этой причине свалил на pdns. Тот тоже не кеширует, но простой как угол дома, в отличие от bind. В плане DLZ/LDAP
Знаете, я первый раз настраиваю DNS-сервер вообще. Изначально хотел djbdns из-за его неломаемости, но остановился на BINDе из-за обилия функционала.
Апач вот тоже обильно функционален, только вот почему-то многие уходят на nginx.
BIND в принципе проще, сам с него начинал — хорошо документирован.
Но вот как-то у меня помоему уже все знакомые, кто работает в провайдерах с него поуходили с одной аргументацией — «тормозной».
А почему должен? СУБД с этим вполне справится.
В чем преимущество лишней точки отказа?
Меня прекрасно устраивала работа бинда на 50к файлов зон
Для начала переведу ответ на Ваш вопрос с официального сайта:
  • BIND считывает данные из текстовых файлов. Очень просто сделать ошибку при его редактировании, приведя к тому, что BIND считает его неправильно или не считает вообще.
  • BIND хранит все данные о ДНС в оперативной памяти. Если Ваш ДНС сервер является авторитарным для множества зон, Вам может быть придется пересобирать ядро для удовлетворения нужд Вашего ДНС сервера.
  • BIND парсит файлы с зонами при старте. При большом количестве зон это может занять много времени. Если Вы меняете какую-то информацию в файлах зон, Вам придется перезапустить BIND, чтобы изменения вступили в силу. Если Вы будете это делать часто, то BIND будет тратить больше времени на загрузку данных, чем на обслуживание запросов.


И от себя скажу: мне зоны в mysql удобнее тем, что, если мне нужно кому-то дать доступ к изменению зоны, я могу дать доступ к конкретной таблице конкретной базы mysql, а не доступ к редактированию файлов на серваке и рестарту BINDa.
>BIND считывает данные из текстовых файлов. Очень просто сделать ошибку при его редактировании, >приведя к тому, что BIND считает его неправильно или не считает вообще.
откройте для себя named-checkconf и named-checkzone

>BIND хранит все данные о ДНС в оперативной памяти. Если Ваш ДНС сервер является авторитарным для >множества зон, Вам может быть придется пересобирать ядро для удовлетворения нужд Вашего ДНС >сервера.
памяти занимает копейки. 50К зон помещаются в гиг памяти

>BIND парсит файлы с зонами при старте. При большом количестве зон это может занять много времени.
мы бинд стартуем всего один раз (при старте системы)

>Если Вы меняете какую-то информацию в файлах зон, Вам придется перезапустить BIND, чтобы >изменения вступили в силу. Если Вы будете это делать часто, то BIND будет тратить больше времени на >загрузку данных, чем на обслуживание запросов.
named-checkzone rndc reload
Зачем Вы говорите все это мне? Я в самом начале своего ответа Вам сказал, что это аргументация разработчиков DLZ. Причина, по которой DLZ использую я, начинается со слов «И от себя скажу:».
Т.е. ни одного аргумента, что я привел, вы не опровергли.
А как же проекты wwwdns, mysql-bind, вебмин и еще штук 5 бесплатных панелей с разграничением доступа?
Вы намеренно их проигнорировали, чтоб рассказать про свой ненадежный велосипед.

«Т.е. ни одного аргумента, что я привел, вы не опровергли.»

Совершенно верно, так как Ваши контраргументы приведены не к моим словам, а лично у меня нет достаточно опыта, чтоб на них возразить или с ними согласится. А вот на следующее я постараюсь ответить.

А как же проекты wwwdns, mysql-bind, вебмин и еще штук 5 бесплатных панелей с разграничением доступа?
Вы намеренно их проигнорировали, чтоб рассказать про свой ненадежный велосипед.

mysql-bind смотрел, если Вы про этот патч. Даже он был первым, на что я обратил внимание. Посчитал, что DLZ интегрированный в bind (а я писал в своем посте, что DLZ с 2005-2006 годов входит в BIND) надежнее, чем сторонний патч, чье развитие остановилось в 2007 году.

wwwdns, я так понимаю — это: stbrat.narod.ru/wwwdns/. Опять же странный скрипт из 2007 года, размещенный на народе вряд ли надежнее массовоиспользуемого phpMyAdmin или тем более самописного простейшего скрипта для работы c MySQL.

webmin — гигантский комбайн с на 90% излишним функционалом. Вообще стараюсь его избегать на серверах.

И у всего Вами перечисленного есть очень большой ДЛЯ МЕНЯ недостаток. Для них нет ебилдов. Я способен, скомпилировать и установить сам программу или скрипт, но предпочитаю это делать из готовых решений, особенно с учетом вышеприведенных доводов.
рестарту BINDa

rndc reload example.com, не?
не знаю — не знаю.
что будет быстрее и менее кушать трафик:
синхронизация мастер-слейв средствами Бинд'a
синхронизация через rsync и последующим релоад изменившихся зон
или
синхронизация MySQL (master-slave)
Тут наверное стоит также упомянуть о возможности репликации Ваших баз между хостами, а следовательно, более быстром обновлении файлов зон на вверенных Вам серверах.
Единственное преимущество этого то что обращаться к базе при изменении зоны удобнее нежели лопатить файлы. И хорошо когда зона с 20-30ю записями, у меня есть зоны и по 500-1000 записей. Я к тому что какую то сфеерическую панель управления зонами легче делать если bind обращается к базе, а не текстовым файлам.
Это не отменяет того что надо перечитывать бекенд.
В даннном случае меня выручил powerdns + его хоть кривое апи с бекендом в постгресе.
Мне кажется вас спасет PowerDNS.
Возможно спасет. Сейчас я на этапе экспериментирования и первоначальной настройки DNS вообще. BIND настроил, собрав некоторую не очевидную информацию, поделился ею с хабраобществом. Далее потестирую сам, посмотрю, возможно перейду на PowerDNS, он же умеет кешировать dns запросы, передаваемые дальше?
там есть свой кешер, отдельно висящий
Большое спасибо за ссылку. Очень интересно.
Там нет самого главного: кол-во доменов, при которых вдруг возникает якобы 100% нагрузка.
По моим данным, при прочих равных BIND обслуживает процентов на 30 меньше запросов в секунду чем NSD. Судя по тестам DLag'а DLZ с мускулем делает этот разрыв еще больше. Что в общем-то очевидно, так как DLZ на каждый запрос лезет в базу, а скорости это не добавляет. Вывод из этого можно сделать такой: если планируется большой qps, DLZ использовать нельзя.
Плюс невозможность сделать нормальный master-slave, из-за чего возникает необходимость держать на каждом сервере по БД и реплицировать ее. Плюс нельзя использовать динамические обновления.
Короче на мой взгляд гораздо правильнее использовать, скажем, динамические обновления (которые с той же базой увязать совершенно несложно), IXFR и rndc addzone/delzone.
НЛО прилетело и опубликовало эту надпись здесь
У меня все хранится в мускуле, так что мне просто так удобнее. В любом случае я перешел на PowerDNS.
НЛО прилетело и опубликовало эту надпись здесь
и api, чтобы не лезть в sql, но оно как-то странно пахнет :(
Запустил на центоси, вроде работает. Добавил поддомен — работает, пинг выдает ip из мускуля. Но при изменении адреса в базе он не меняется при пинге с компа. dns-кеш винды чистил. Провайдер мой кеширует?
Спасибо, дело оказалось в содержимом поля ttl. Указал поменьше (меньше 60 сек нельзя) — все стало срабатывать через минуту без очисток кеша винды. Пошел дальше — делаю бесплатный ddns-сервис :) Скоро запущу.
Перед тем как что-то такое «запускать» я бы на Вашем месте досконально разобрался с вопросом. А то судя по первому комменту, уровень понимания работы технологии у Вас, мягко говоря, не очень.
Давайте мы разберем ваше утверждение. Я задавал вопросы о том, с чем еще не имел дела плотно — bind. Я получил два ответа, точнее, два неправильных ответа на хабре. И до оставшихся нюансов докопался сам, причем быстрее, чем пришли эти ответы.

Это характеризует мой уровень в оставшихся вопросах проекта — mysql, php, jquery, javascript, настройки apache и его модов, настройки операционной системы linux, прочие вещи, требуемые проектом?

Тот факт, что мне еще не приходилось сталкиваться с bind, принижает мой уровень в рамках всех знаний и умений?
Я вас попрошу, уважаемый. Я понимаю, что большая часть «сисьадминов» с завышенным ЧСВ по жизни, но это не значит, что это оправданно.

Можете минусить.
Вы задали вопрос по DNS. в рамках Ваших знаний по DNS я Вам характеристику и выставил, а
"
mysql, php, jquery, javascript, настройки apache и его модов, настройки операционной системы linux, прочие вещи, требуемые проектом?
"
Вы приплели сюда сами, я Вас не просил.

PS — MySQL уже тоже, кхм, не очень любят, кроме оставшихся шаредхостингов с вордпрессами — ни одного серьезного продукта на MySQL я последние несколько лет не видел.

dns ttl — это базовые знания, и не знать такое, и при этом еще что-то пытаться делать на основании технологии, в которой Вы не разобрались до конца — попахивает не очень
Ну, если ничего не делать — ничего и не получится. Теорию, конечно, прошерстю более детально, чем сейчас. Когда буду ближе к основному запуску, после тестирования. Но от технологии, по сути, и требуется минимум. Опять же — базовые знания получены сегодня в большом количестве.
Жив ли автор?)
Вопрос — для NS-записей обязательно указывать NULL в retry, expire, serial и тд?
Powerdns + PostgreSQL гораздо интереснее и пошустрее будет. Эталонная реализация стандарта не всегда хороша.
Жив.
Вопрос не совсем понял. Обязательно ли указывать, что поля могут быть NULL при создании структуры? Нет. Но так Вам будет удобнее.
Обязательно ли указывать NULL при добавлении записи? Конечно, нет, они для этого и могут быть NULL — мускуль за Вас "подставит" NULL, если Вы просто опустите заполнение этих полей.

Но хочу сказать, что я забил на BIND примерно через месяц после написания этой статьи, и с тех пор вполне успешно использую powerdns+mysql.
Я об этом же.
На рекурсивных серверах у меня что-то около 2х кратного прироста.

А вот что с мониторингом делать, например те же DoS атаки на запрос ./localhost?
Как Вы сделали логи?
Ну, честно, говоря, у меня как-то не было проблем с DNS-cерверами, поэтому я
1) логи запросов не пишу
2) если нужен будет серьезный мониторинг: прикручу к заббиксу, у меня большой опыт написания внешних проверок для него.
3) Для защиты от DoS или чтоб не быть плечом для DDoS на серверах, которым необходимо быть публичными, я просто лимитировал частоту запросов с помощью iptables.
у меня тут ну очень большая сетка /1_, пока был bind и один запрос в одной строке лога — влёгкую можно было получить полтора миллиона запросов .|localhost IN A с проломанного клиента. легким пинком fail2ban особо упоротые клиентские IPшники улетали в сад iptables. После звонка "почему у меня интернет не работает" обычно проблема решалась на корню.

PDNS, конечно, влегкую обрабатывает где-то так в 2-2,5 раза больше запросов, но вы же не будете траффик снифферить, чтобы понять top'овых запрашивателей локалхоста? Вот, собственно, я по этому про логи и спрашивал. у рекурсора и мастера немного разные кодовые базы и статистика разнится.
А насчёт заббикса — я бы с удовольствием послушал — Nagios сидит в печёнках, а вот как мониторить тот же конкретный рекурсивный сервер DNS с забикс сервера я пока не придумал.
Промазал веткой. Ответ тут.
Да у меня запросы маленькие, 3-5 тыщ записей, бинд справляется легко. Пока это так и останется — меня устраивает, переделывать тупо некогда.
Но — хочется ptr.
Я так понимаю, надо запросы в конфиге доводить?
А насчёт заббикса — я бы с удовольствием послушал — Nagios сидит в печёнках, а вот как мониторить тот же конкретный рекурсивный сервер DNS с забикс сервера я пока не придумал.

Бегло погугля, понимаешь, что все придумано до нас: снимаем информацию через rec_control и складываем в заббикс.
у меня рек_контрол так и не завелся, таймаут и хоть убейся.
с мастера снимается нормально
У меня с нуля нормально выдает информацию. Что на дебиан, что на генту. Вы сокеты\конфиги перемещали куда?
ничего никуда не перемещал, таймаут и всё на centos6 + внешняя репозитория для 3.х какого-то
Сейчас обновил рекурсор с ихнего официального репозитория на тестовый, конфиг тот же, все работает.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории