В настоящее время в нашей корпоративной сети есть первичный и вторичный DNS-серверы. Они настраиваются в настройке типа главный / подчиненный, где подчиненное устройство получает информацию о DNS от главного устройства.
Я пытаюсь выяснить, в чем реальное преимущество настройки ведущего / ведомого устройства вместо простой настройки автоматического rsync между ними, чтобы настройки DNS совпадали.
Может кто-нибудь пролить некоторый свет на это? Или это просто привилегия? Если это так, похоже, что настройку rsync будет намного проще настроить, поддерживать и понимать.
На самом деле здесь много всего происходит, но многое из этого может не иметь отношения к вашей ситуации.
Во-первых, использование взаимоотношений DNS "главный / подчиненный" позволяет легко реплицировать серверы разных типов. Я знаю, что синхронизировал основной сервер OS X Server (BIND?) С Windows DNS.
Это также позволяет указать, что вторичная система DNS может получать данные с разных первичных серверов для разных зон (и наоборот). Практический пример: мы использовали нашу собственную систему DNS и передали на аутсорсинг дополнительный вторичный DNS для обеспечения надежности.
Таким образом, также легко расширить DNS-серверы. Вы просто добавляете новое подчиненное устройство в список вместо добавления дополнительного сервера имен, настройки дополнительной репликации и т. Д. Это сохраняет процесс относительно автономным.
Конфигурация главный / подчиненный (также известная как «зональные передачи», AXFR или IXFR) - стандартная конфигурация, используемая большинством DNS-серверов. Уже по одной этой причине я рекомендую это, даже если это сложно.
Хотя я рекомендую его для обеспечения совместимости и того, что это легко понять другим администраторам, это не означает, что это технически лучший способ сделать это.
Даниэль Бернштейн (из djbdns/tinydns) сильно предпочитает rsync и имеет эта таблица сравнения rsync по сравнению с зонными трансферами. rsync отлично работает с tinydns но я никогда не пробовал с bind.
Если вы попробуете, имейте в виду, что вы, вероятно, напишете сценарий, который запускается cron. Другой администратор, который просматривает вашу конфигурацию DNS, не обязательно будет знать об этом или знать, где найти сценарий синхронизации. Напротив, обычная конфигурация передачи зоны находится прямо в ваших файлах зоны, что делает ее явной. Имеет ли это значение, зависит от того, со сколькими другими администраторами вы имеете дело и насколько они информированы о вашей конфигурации DNS.
Есть несколько причин использовать AXFR / IXFR а не rsync:
Это стандартно и работает во всех соответствующих реализациях. Это позволяет вам смешивать серверы - возможно, если вы хотите обеспечить отказоустойчивость в случае проблемы с безопасностью с одним из ваших поставщиков.
Это быстро - изменения на главном сервере могут быть реплицированы на второстепенные в течение нескольких секунд, если вы используете NOTIFY механизм. (мастер сообщает вторичным компонентам, что зона изменилась, а затем вторичные компоненты могут захватить изменения с помощью IXFR).
Это надежно - нет никаких шансов, что ваш сервер каким-то образом получит наполовину скопированный файл и решит, что это весь файл.
FWIW, мы используем IXFR здесь на очень большая зона. Это «просто работает».
Предполагая BIND здесь.
Мне кажется, что использование rsync - это не только больше проблем, оно просто создает больше проблем, которые могут пойти не так, возможно, оставляя ведущее и ведомое устройство не в ногу.
Похоже, что rsync и IXFR будут делать примерно одно и то же. Например, у вас будет хорошая синхронизация от bind9-> bind9, но если вам нужно перейти от bind8-> bind9 или bind-> Microsoft, передача зоны должна работать, несмотря на различия в бэкэнде. Плюс к использованию только rsync, как я вижу, заключается в том, что вы можете полностью отключить передачу зон, что хорошо с точки зрения безопасности.
Мы запускаем bind с rsync с 1995 года - работает нормально - сегодня есть много причин для перехода на tinydns и / или зональные передачи, но логика тогда, и почему мы застряли с ней сегодня, заключается в том, что один сервер каким-то образом там был взломан не является истинным «первичным», чтобы затем воспроизвести проблему другим.
Тем не менее, наличие основного внутреннего для вашей локальной сети и доступных через Интернет ведомых устройств также решает проблему.
Мы выталкиваем rsync и перезагружаем их с помощью скриптов, наряду с некоторыми проверками работоспособности - если вы пойдете по этому маршруту, подумайте о добавлении всех этих частей, если что-то пойдет не так - вы ДЕЙСТВИТЕЛЬНО не хотите, чтобы ваши DNS-серверы были отключены или даже отсутствовали зоны.
Обычно я делаю то, что естественно для данной ситуации.
При использовании связывания, в зависимости от ситуации, я обычно запускаю 2 мастера и несколько подчиненных.
Изменения внесены одним мастером; эти изменения проверяются, а затем передаются другому мастеру. Этот мастер использует передачи zoen для отправки зон на DNS-серверы, которые видят клиенты. Два других не рекламируются. (первый мастер не обязательно, но неплохо иметь царапина обезьяна) Мне также нравится иметь 2 копии конфигураций сервера и 2 копии файлов зон в правильном формате (вместо копии, которую вы получаете на подчиненном сервере). Необходимо следить за тем, чтобы сервер перезагружал только зоны. после rsync завершается.
Когда вы используете AD для DNS, вам не нужно беспокоиться об обмене зонами между серверами - протоколы AD волшебно позаботьтесь о синхронизации всего.
PowerDNS ожидает, что вы будете использовать передачу зон или какой-то механизм репликации базы данных для синхронизации.
TinyDNS может использовать передачу зон, но если вы передаете файлы внутри одной организации, имеет смысл использовать что-то вроде rsync, потому что сервер tinydns делает перезагрузку зон безопасной и простой.
Наконец, что наиболее важно, используйте перенос зон, если вы обмениваетесь зонами DNS с организациями, находящимися вне вашего прямого контроля. Например, это обычное дело, когда у вашего интернет-провайдера есть авторитетный сервер для клиентов. Этот сервер будет подчиненным сервером и будет получать зоны посредством передачи зон, независимо от того, какой тип DNS-сервера использует клиент. Точно так же, если я передаю свой DNS на аутсорсинг провайдеру, например UltraDNS, я буду настаивать на том, чтобы иметь возможность выполнять перенос своих зон со своих серверов, поэтому я могу оставить их в любое время, обновив регистраторов, чтобы они использовали мои серверы вместо их. как авторитетные серверы для моих доменов.