Обсуждение статьи тематического каталога: Автоматическая синхронизация master и slave DNS серверов (dns sync domain bind freebsd)Ссылка на текст статьи: https://www.opennet.ru/base/net/dns_sync.txt.html
имхо, статья о том, как не надо делать. для таких целей есть директива masters в named.conf
Если вы расскажете как поставленную задачу решить средствами бинд - я удалю эту статью и попрошу извинения у читателей. Но что-то мне подсказывает, что дальше заголовка вас читать не научили.
Велосипед. Зачем придумано master и slave в намеде - автору явно не известно.
>Велосипед. Зачем придумано master и slave в намеде - автору явно не
>известно.Жду решения задачи описанной в статье встроенными средствами.
Автор, объясните пожалуста смысл действий. А то народ в недоумении, может я чего не допонял/не знаю? : (
>Автор, объясните пожалуста смысл действий. А то народ в недоумении, может я
>чего не допонял/не знаю? : (Смысл действий ясно описан в статье - автоматическое создание и удаление зон на слейвах, в зависимости от конфигурации мастера.
спасибо, но я буду пользоваться встроенными в бинд средствами синхронизации :))
>спасибо, но я буду пользоваться встроенными в бинд средствами синхронизации :))+1 :)
Автор, отсыпь :)
Да не вопрос, обращайся. Только до этого опиши, как решить задачу распространения вновь созданных или удалённых зон встроенными средствами. Отсыплю стакан.
Дико извиняюсь, таки недосмотрел и не до конца внимательно прочитал, а так, бегло, между строк...
Идея отличная.
Попроси лучше вебмастеров/админов сайта переименовать статью :)
Не страшно, да и с названием я и в самом деле накосячил. Заявку на изменение названия сразу отправил, надеюсь завтра поправят. Просто не понимаю, зачем писать комментарии к тексту не прочитав его.
более того, встроенные средства красиво оформляют файлы зон =)
>более того, встроенные средства красиво оформляют файлы зон =)И распространяют вновь созданные? Почитайте статью. Название и в самом деле неудачно,
С ума сойти... ну понятно когда такое проделывают с djb dns, но с named, имхо - извращение...
А слабо комментаторам прочитать статью ? Речь про то как _автоматически_ синхронизировать зоны на слейв, без ручной правки конфигов слейва, просто добавил домен на мастере, он сам заведется на слейве. У меня например это делается формированием конфига слейфа на стороне мастера и последующим его копированием.
Но это должно делаться только один раз при создании зоны
А если слейвов >> 1? А если это должно происходить автоматически? Например, на мастере вписывают зоны из веб-панели. Ну и? Дальше что?
>А если слейвов >> 1? А если это должно происходить автоматически? Например, на мастере вписывают зоны из веб-панели. Ну и? Дальше что?Не досмотрел...
статью правильно надо было назвать: Автоматическое создание slave зон DNS.
И то в скрипте высмотрел, что не перестартовывается DNS если нет обновление. А по тексту это не совсем так. Каждый раз скрипты читать...
>>А если слейвов >> 1? А если это должно происходить автоматически? Например, на мастере вписывают зоны из веб-панели. Ну и? Дальше что?
>
>Не досмотрел...
>статью правильно надо было назвать: Автоматическое создание slave зон DNS.
>И то в скрипте высмотрел, что не перестартовывается DNS если нет обновление.
>А по тексту это не совсем так. Каждый раз скрипты читать...
>Название было выбрано неудачно, согласен. Хотя в тексте ясно написано о чём идёт речь.
>А если слейвов >> 1? А если это должно происходить автоматически? Например, на мастере вписывают зоны из веб-панели. Ну и? Дальше что?Кстати, именно так и происходит. Зоны создаёт менеджер - реселлер из веб морды. Географически разнесённых слейвов больше одного. И вообще есть мысль в целях безопасности настоящий мастер сделать скрытым, чтобы с него только слейвы и кормились.
>Но это должно делаться только один раз при создании зоныПосмотрите вы скрипт в статье в конце концов, там вся его работа сводится к автоматическому формированию slave.conf, передается через ssh каждый раз только список доменов.
>>Но это должно делаться только один раз при создании зоны
>
>Посмотрите вы скрипт в статье в конце концов, там вся его работа
>сводится к автоматическому формированию slave.conf, передается через ssh каждый раз только
>список доменов.Большое спасибо что прочитали статью, ваш IQ явно много выше большинства пишущих тут :)
>Но это должно делаться только один раз при создании зоныПочитайте статью. Зон - порядка сотни, и правит их менеджер через веб морду. Задача решалась для небольшого хостинг-провайдера.
>А слабо комментаторам прочитать статью ? Речь про то как _автоматически_ синхронизировать
>зоны на слейв, без ручной правки конфигов слейва, просто добавил домен
>на мастере, он сам заведется на слейве. У меня например это
>делается формированием конфига слейфа на стороне мастера и последующим его копированием.
>Большое спасибо что смогли прочитать дальше заголовка (в отличии от большинства муд.. комментаторов).
Может книжку в начале почитал бы? А то читать тошно...
>Может книжку в начале почитал бы? А то читать тошно...Книжку по магии ? У вас конфигурационный файл slave сервера волшебным образом создается ? Чтобы средствами DNS перетащить зоны, нужно вначале эти зоны в конфиге обозначить связав их с мастером.
>Может книжку в начале почитал бы? А то читать тошно...Тошно - не читайте. А теперь скажи мне, мой слаткий, в какой книжке это описано?
pDNS
Да, это 1 из вариантов, я его рассматривал, но всё же решил остановиться на бинд, ввиду его лучшей изученности :)
Почти все, кто сверху - идиоты. Речь идет о синхронизации зон и их содержания, а не только содержания. Некоторое время назад мне тоже пришлось решать такую задачку.
>Почти все, кто сверху - идиоты. Речь идет о синхронизации зон и
>их содержания, а не только содержания. Некоторое время назад мне тоже
>пришлось решать такую задачку.Встречают по одежке...
Это я к чему - название статьи правильно надо писать!
>>Почти все, кто сверху - идиоты. Речь идет о синхронизации зон и
>>их содержания, а не только содержания. Некоторое время назад мне тоже
>>пришлось решать такую задачку.
>
>Встречают по одежке...
>Это я к чему - название статьи правильно надо писать!Да, это была моя ошибка. Но писать комментарии к статье НЕ ЧИТАВ ЕЁ - это идиотизм. Клинический.
Афтар, что мешало передать файл конфига по ftp? К чему такие сложности?
Не автор не все же как Ранович отвечу вопросом на вопрос - а если слейв в десяти-двадцати транзитных общедоступных для других сеток от мастера и никто никому не мешает мирроринг на порту свитча включить и сниффить? И просниффить аккаунт для фтп?
>Афтар, что мешало передать файл конфига по ftp? К чему такие сложности?
>1) ftp не безопасен.
2) Передать файл откуда? На мастере - совсем другая конфигурация.
3) Где вы увидели сложности? Задача решена исключительно средствами ОС. С фтп решение бы заняло не меньше времени и скрипт всё равно бы пришлось писать.
А rsync не лучше заюзать? Я понимаю, это конечно выходит за рамки средств ОС. но тем не менее.
>Афтар, что мешало передать файл конфига по ftp? К чему такие сложности?
>Наверно, отличный от нуля IQ автора статьи помешал. Вам, наверно, не помешает.
Читаем новость:Alex Samorukov подготовил статью с рассказом как обеспечить автоматическую синхронизацию конфигурации первичного и вторичных DNS серверов.
Что неясно, мои милые лемминги?
>Читаем новость:
>
>Alex Samorukov подготовил статью с рассказом как обеспечить автоматическую синхронизацию конфигурации первичного
>и вторичных DNS серверов.
>
>Что неясно, мои милые лемминги?Саш, плюнь и не заводись. Здесь многие сначала поливают, потом думают. Столкнутся с похожей проблемой - прибегут и будут читать. И еще спасибо скажут. А до тех пор: "а на.. оно надо? А зачем велосипед?". Многие просто не сталкивались с чем-то серьезнее одного роута в компании и все. :) Решение не безгрешное, но имеет право быть.
Samm, идея отличная и реализация тоже. Спасибо.
Статья понравилась. Спасибо.
"Теоретикам", написавшим максимум "hello, word" в своей жизни нужно научиться уважать людей, которые умеют генерить идеи и воплощать их в жизнь...
Скрипт стоит подправить, чтобы срабатывало не по крону, а скажем вызывалось скриптом на мастере, после правки конфига, этот скрипт также могбы рестартовать named на мастере. В итоге, слейв синхронизируеться сразу, и нету ненужных синхронизаций в период когда конфиги не правились.
>Скрипт стоит подправить, чтобы срабатывало не по крону, а скажем вызывалось скриптом
>на мастере, после правки конфига, этот скрипт также могбы рестартовать named
>на мастере. В итоге, слейв синхронизируеться сразу, и нету ненужных синхронизаций
>в период когда конфиги не правились.В этом есть и плюсы и минусы. Ну плюс очевиден - нет лишних обращений к мастеру. Минус тоже - во первых у всех клиентов должен быть для этого заведён ssh account, во вторых - если кто-то временно не доступен (как я уже говорил, сервера разнесены) то синхронизация не произойдёт (и мы должны это учитывать в скрипте). Я решил пойти по варианту большей надёжности, тем более что трафик, по сегодняшним меркам, оно создаёт крошечный.
во первых не совсем понял о чём Вы говорите "у всех клиентов должен быть для этого заведён ssh account"
ну на случай если кто-то временно не доступен (у меня тоже сервера разнесены ;) ), то можно раз в сутки действительно делать по крону (и не обязательно со слейва)но основной плюс от продложеной мной схемы не отсутствие лишних запросов, а мгновенная синхронизация.
Это не сложно добавить, просто для моей задачи время синхронизации до 10 минут было совершенно допустимым. Кроме того, я бы не хотел чтобы на каждый чих рестартавали слейвы, лучше уж пусть какой-то лаг будет. Но, повторюсь, это - индивидуально.
"Если ключ ещё создан"
Видимо пропущена "не".Alex, а по -HUP named не перечитывает конфиг?
Судя по документацииCertain UNIX signals cause the name server to take specific actions, as described in the following table. These signals can be sent using the kill command.
SIGHUP
Causes the server to read named.conf and reload the database.перечитывает. На практике у меня пару раз он "волшебным образом" исчезал из списка процессов и, исключительно для надёжности, я вписал рестарт. Можете заменить если это критично.
>"Если ключ ещё создан"
>Видимо пропущена "не".
>
>Alex, а по -HUP named не перечитывает конфиг?Да, и спасибо за "ключ ещё не создан" - действительно опечатка, послал запрос на исправление.
Сам в 96-ом году так-же парился, выкрутился подобным способом. Я думаю, для тех людей у кого голова дана не "для того, чтобы шляпу носить" - данная статья будет хорошим подспорьем.
пипец, кто писал выше в начале клинические дибилы, прочитав заголовок я почемуто СРАЗУ понял о чем статья.
по теме:
1) статья вери гут
2) вопрос к знатокам - а как быть если доменов планируется 5 000 - 10 000, юзать как бэкенд лдап или мускуль ?
однакож читал что с производительностью проблемы в таком случае....
ваши мнения ?
>пипец, кто писал выше в начале клинические дибилы, прочитав заголовок я почемуто
>СРАЗУ понял о чем статья.
>по теме:
>1) статья вери гут
>2) вопрос к знатокам - а как быть если доменов планируется 5
>000 - 10 000, юзать как бэкенд лдап или мускуль ?
>
>однакож читал что с производительностью проблемы в таком случае....
>ваши мнения ?Ну я бы решал задачу так:
1) Перевёл бы мастер и слейвы на SQL драйвер конфигурации, например - отсюда (MySQL) http://mysql-bind.sourceforge.net/ .
2) Настроил бы репликацию MASTER->SLAVES в mysql, кстати, при этом можно без проблем включить SSL шифрование и ограничение IP (средствами MySQL). Это бы обеспечило автоматический и надёжный механизм распространения конфигов и баз. Желательно также сделать мониторинг баз данных на слейвах, чтобы не пропустить момент рассинхронизации.
3) Я не думаю, что на современном железе у вас возникнут проблемы с производительностью, если вы конечно не собираетесь строить root сервер ;-) Обычно dns жрёт достаточно небольшое количество ресурсов. В крайнем случае - можно поставить обычный named в роли кеширующего. Ну и в MYSQL5 покрутить (query cache и т.п.).
Спасибо за отзыв =) пайду читать.
>[оверквотинг удален]
>
>Ну я бы решал задачу так:
>1) Перевёл бы мастер и слейвы на SQL драйвер конфигурации, например -
>отсюда (MySQL) http://mysql-bind.sourceforge.net/ .
>2) Настроил бы репликацию MASTER->SLAVES в mysql, кстати, при этом можно без проблем включить SSL шифрование и ограничение IP (средствами MySQL). Это бы обеспечило автоматический и надёжный механизм распространения конфигов и баз. Желательно также сделать мониторинг баз данных на слейвах, чтобы не пропустить момент рассинхронизации.
>3) Я не думаю, что на современном железе у вас возникнут проблемы
>с производительностью, если вы конечно не собираетесь строить root сервер ;-)
>Обычно dns жрёт достаточно небольшое количество ресурсов. В крайнем случае -
>можно поставить обычный named в роли кеширующего. Ну и в MYSQL5
>покрутить (query cache и т.п.).
Спасибо за статью.
Начал читать то же сразу не догнал, зачем так делать.
Потом понял в чем смысл.
Мне кажется название статьи лучше поменять на что нибудь такое: автоматическая синхронизация списка доменных зон ...
И в пункте "Зачем это нужно?" акцент на это сделать.
Спасибо за статью !
Давно хотел найти нечто подобное.
У меня только один вопрос.
А почему нельзя читать зоны из named.conf ?
При этом выборку делать по типу зоны и брать записи только с типом master.
У меня, например сервер, являющийся мастером для одних доменов, в то же время является слэйвом для некоторых других.
И мне трудно заставить, например Plesk, разделять мастер и слэйв зоны по разным директориям и писать файлы зон с окончанием ".db"
Можно ли как то сделать выборку мастер зон из named.conf для передачи их Вашему скрипту ?
Спасибо !
>Спасибо за статью !Пожалуйста )
>Давно хотел найти нечто подобное.
>У меня только один вопрос.
>А почему нельзя читать зоны из named.conf ?Можно, конечно, просто это услоэнит задачу.
>При этом выборку делать по типу зоны и брать записи только с
>типом master.
>У меня, например сервер, являющийся мастером для одних доменов, в то же
>время является слэйвом для некоторых других.В данном примере случай частной задачи, не более.
>И мне трудно заставить, например Plesk, разделять мастер и слэйв зоны по
>разным директориям и писать файлы зон с окончанием ".db"
>Можно ли как то сделать выборку мастер зон из named.conf для передачи
>их Вашему скрипту ?
>Спасибо !Можно, конечно. С плеском я бы поступил иначе - весь конфиг он хранит в mysql, так что просто на сервере сделайте скрипт из mysql + sed :)
> С плеском я бы поступил иначе - весь конфиг он хранит в mysql, так что просто на сервере сделайте скрипт из mysql + sed :)Спасибо за совет.
И как я раньше не догнал ?))
Статья - ради статьи :(
Теперь предлагается сделать форки этой статьи о пересылке и разборе файла named.conf по почте (и разбирать procmail), по ftp, по http, по .......
Тут можно список продлить.
А потом добавить весь перечень статейсписок с использованием AWK, perl etc....
>Статья - ради статьи :(
>Теперь предлагается сделать форки этой статьи о пересылке и разборе файла named.conf
>по почте (и разбирать procmail), по ftp, по http, по .......
>
>Тут можно список продлить.
>А потом добавить весь перечень статейсписок с использованием AWK, perl etc....Я надеюсь, что кому-та эта статья здорово сократит время для реализации данной задачи.
Спасибо за статью
Сейчас пользую самописный скрипт scp/ssh для синхронизации 3-х серверов, но у меня его нужно запускать ручками
На неделе буду внедрять!
Начало статьи однозначно говорит о том, что автор собирается синхронизировать именно файлы зон.
Отсюда и весь сыр, бор.Вот пример:
"Для одного из проектов мне потребовалось обеспечить автоматическое
распространение DNS зон, прописанных на master dns, slave серверам."Любой прочитавший это сразу задастся вопросом: А на кой сие? Сам BIND это умеет и даже очень хорошо умеет.
Даже смена названия статьи не сдерживает негатива от прочтения.
Так же не освещена тема когда зона с основного сайта удаляется. На резервном сервер ведь мусор остается. Как его стирать прикажите? Могу дать идею. Надо пройтись AWK-ом по файлу named.conf и все файлы, которые там не указаны удалить из соответствующего каталога.
Вот тогда будет действительно хорошее и полезное решение.
Согласен.А автора статьи за обзывания забанить. :D
>Согласен.
>
>А автора статьи за обзывания забанить. :DДа ради бога! Пожалуйтесь редактору.
>Начало статьи однозначно говорит о том, что автор собирается синхронизировать именно файлы
>зон.
>Отсюда и весь сыр, бор.
>
>Вот пример:
>"Для одного из проектов мне потребовалось обеспечить автоматическое
>распространение DNS зон, прописанных на master dns, slave серверам."
>
>Любой прочитавший это сразу задастся вопросом: А на кой сие? Сам BIND
>это умеет и даже очень хорошо умеет.Да? умеет распространять зоны мастера, не прописанные на слейвах? А в ISC про это знают?
>
>Так же не освещена тема когда зона с основного сайта удаляется. На
>резервном сервер ведь мусор остается.Ну остаётся и ладно, меня не напрягает наличие мусора в дире слейв. Если вас напрягает - 2 строчке в скрипте-апдейтере, diff + awk + xargs и всё. В любом случае они НИ НА ЧТО не влияют.
в PowerDNS задача отлично решается встроенными средствами. И испортировать зоны из бинда тоже можно. Имхо нет смысла изобретать велосипед.
> Да? умеет распространять зоны мастера, не прописанные на слейвах? А в ISC про это знают?Умеет, знают.:) Ловите нотификации - они присылаются на слэйвы независимо от того - прописано там что-то у них в конфигах, или нет:
14-May-2008 18:06:20.053 notify: info: zone sxxxxxxxxxxxx/IN/regular: sending notifies (serial 20080426)
>> Да? умеет распространять зоны мастера, не прописанные на слейвах? А в ISC про это знают?
>
>Умеет, знают.:) Ловите нотификации - они присылаются на слэйвы независимо от того
>- прописано там что-то у них в конфигах, или нет:
>14-May-2008 18:06:20.053 notify: info: zone sxxxxxxxxxxxx/IN/regular: sending notifies (serial 20080426)С точки зрения security крайне стрёмное решение )
Alex, мне кажется у тебя в статье закрался один косяк "по процедуре"вот в этой строке
/bin/ls *.db|/usr/bin/sed 's/\.db//'будут неправильно обрабатываться домены типа domain.dbxxxxx.com и т.д.
т.е. содержащие .db внутри имени доменарешается банально:
/bin/ls *.db|/usr/bin/sed 's/\.db$//'но лучше в статье написать правильно - некоторые могут наступить на эти грабли, огорчатся потом ...
Про статью вообще - задачка довольно специфическая, но решение адекватное - дёшево и сердито.
Интересное решение, простое и надежное. Репликация базы имеет свои риски и тонкости, например упасть может MySQL, база попортиться может, да и вообще любое лишнее звено снижает надежность. А то можно дойти до того, что давайте все конфиги в базе хранить, а /etc удалим за ненадобностью :)Можно предложить улучшение: файлы копировать через rsync. Он по ssh работает, передает только диффы и сжимает данные. Трафик будет виден только под микроскопом.
У нас была аналогичная проблема на MS DNS серверах (тоже хостинг-провайдер где клиенты добавляют домены через веб интерфейс).
Нашли готовый софт:
http://tools.tripletee.com/3tdns/
Hi!идея отличная. Сам писал подобное (с учетом специфики своей задачи) на основе shell+rsync(via ssh).
я удивляюсь всяким "комИнтОтАрам" которые банально не одупляют суть вопроса, лишь бы что-то ляпнуть....в духе "аФтор не курил ман бинда"
Спасибо!
Автору спасибо за идею и статью, я тоже боролся с подобной проблемой чуть меньше месяца назад. Читал про многие DNS демоны, но задача стояла (работа с кириллическими доменами), а на данный момент с ними работает только ibind. Поэтому проблемма синхронизации зон - была решена подобным способом с передачей через rsync.
Спасибо автору..