Dns мастер что это: DNS-Hosting RU-CENTER

Запуск подчиненного сервера имен

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

Как сервер узнает, является ли он основным мастером или ведомым для зона? Информация о конфигурации DNS-сервера в реестре сообщает сервер является основным мастером или подчиненным для каждой зоны. Записи NS не говорят нам, какой сервер является основным мастером для зоны и какие серверы являются ведомыми для зоны — они только говорят кто серверы. (В глобальном масштабе DNS это не волнует; насколько фактическое разрешение имен идет, подчиненные серверы так же хороши, как первичные главные серверы.)

Чем отличается первичный главный сервер имен от подчиненного сервер имен? Принципиальная разница заключается в том, где сервер получает свое данные. Первичный главный сервер имен считывает свои данные из файлов. Раб сервер имен загружает свои данные по сети с другого сервера имен. Этот процесс называется передача зоны .

Раб сервер имен не ограничивается загрузкой зон с первичного мастера сервер имен; подчиненный сервер может загружаться с другого подчиненного сервера. большим преимуществом подчиненных серверов имен является то, что вы поддерживаете только один набор файлов данных зоны, те, что на первичном главном сервере имен. Ты не нужно беспокоиться о синхронизации файлов между именами серверы; рабы делают это за вас.

Подчиненный сервер имен не должен извлекать все его файлов данных по сети; в файл cache.dns такой же, как на первичном master, так что держите локальную копию на ведомом.

Совет

Один момент, касающийся ведомых, может сбить с толку: раньше ведомых называли вторичные главные серверы имен. Мы будем использовать термин раб в этом книгу, но вы увидите, что консоль DNS по-прежнему использует термин вторичный. Как мы уже говорили, это синонимы.

Добавить новый сервер в консоль DNS

Первый шаг в настройке подчиненный сервер должен добавить сервер в мир консоли DNS вид. Как и при настройке основного мастера, выберите Действие → Подключиться к компьютеру… , затем ввести IP адрес раб. В этом случае нашим рабом будет Червоточина с IP-адресом 192.249.249.1. Из Конечно, DNS-сервер должен быть установлен и запущен на будущий подчиненный сервер, чтобы консоль DNS могла им управлять.

Создать новую зону

Этот новый сервер будет подчиненным для каждой зоны на первичном, поэтому нам придется пройти процесс новой зоны для каждой зоны. Начнем с movie.edu . Выбирать Действие → Новая зона… . На этот раз выберите Стандартный вторичный (помните, это синоним раб ) во втором окне Мастер. В третьем окне выберите Вперед зона поиска . Четвертое окно показано на рис. 4-23.

Рисунок 4-23. Создание новой вторичной зоны: указание доменного имени зоны

В поле Имя введите домен имя зоны (в данном случае movie.edu ). В поле Server введите IP адрес основного главного сервера имен. Вы можете ввести это информацию или воспользоваться ярлыком, предлагаемым DNS консоль. При нажатии кнопки Browse кнопка, консоль DNS показывает вам вид зон на всех именах серверы, которыми он управляет. Поэтому вместо того, чтобы печатать movie.edu, мы могли бы найти эту зону в окне Browse , как показано на рис. 4-24.

Рис. 4-24. Поиск зоны с помощью окна Browse

Независимо от того, вводите ли вы зону и сервер вручную или используете ярлык Browse , нажмите Next , чтобы открыть следующее окно, показанное на рис. 4-25.

Рисунок 4-25. Создание новой вторичной зоны: указание мастер-серверов

На этом этапе процесс создания первичной мастер-зоны и раб зоны действительно расходятся. Это экран, где вы указываете, где этот сервер имен получит данные зоны. В этом примере мы сделать червоточину рабом для movie.edu Зона . Нам нужно сказать червоточина для загрузки зоны из терминатор , первичный мастер. На самом деле на этом экране вы можете указать несколько IP-адресов. В продвинутом (и сложные) конфигурации, иногда бывает несколько первичных или несколько источников, из которых ведомое устройство может получить информацию о зоне. Консоль DNS поддерживает эти конфигурации. Вы также можете просто укажите IP-адрес другого ведомого после основного: в если первичный не работает, этот ведомый может загрузиться с другого ведомого. Из Конечно, у Movie U. нет другого раба (пока).

Пока мы просто указываем IP-адрес терминатора адрес 192.249.249.3. (Еще раз вы можете нажать кнопку Browse и найти терминатор среди списка DNS-консоли известных серверов имен, чтобы не вводить свой IP-адрес. ) Затем нажмите Далее . Последнее окно в процесс такой же, как и при создании основной зоны: он просто сообщает вам, что вы закончили, и просит нажать Готово . Мы не будем показывать его вам.

Когда вы закончите, новый ведомый немедленно инициирует зону передать на первичный, чтобы загрузить зону. В течение нескольких секунд вы должны быть в состоянии дважды щелкнуть значок подчиненного для зону и просмотреть записи в зоне.

Добавить запись NS для нового подчиненного сервера имен

Твой новый раб не принесет много пользы если остальной мир об этом не знает. Как генерал правило, когда вы добавляете еще один сервер имен для зоны, вам также необходимо добавьте для него запись NS. (Мы обсудим исключения из этого в главе 8.)

Вам необходимо добавить запись NS на первичную зону. (Помнить что все изменения в зоне выполняются на первичном и распространяются автоматически рабам. Не путайте факт что консоль DNS позволяет вам видеть все ваши серверы имен — вы вносим изменения только в первичную зону.) В нашем случае мы необходимо добавить запись NS для червоточины в movie.edu Зона . Итак, мы выделяем movie.edu под терминатор и выберите Действие → Свойства . Нажмите на вкладку Name Servers , и вы увидите окно как на рис. 4-26.

Рис. 4-26. Записи NS для зоны movie.edu

Это окно показывает, что сейчас имеется только одна запись NS для зона movie.edu , которая указывает termator.movie.edu как авторитетное имя сервер. Чтобы добавить еще один, нажмите Добавить… и вы увидите окно, показанное на рисунке 4-27.

Рис. 4-27. Добавление записи NS

Введите имя и IP-адрес подчиненного сервера имен и нажмите ОК .

Не забывайте о зонах in-addr.

Теперь повторите эту ведомую зону процесс создания с 249.249.192.in-addr.arpa и 253. 253.192.in-addr.arpa зоны.

Значения SOA

Запомните эту запись SOA для фильм.edu зона?

 @ IN SOA terminator.movie.edu. администратор.movie.edu. (
                        1; серийный номер
                        3600 ; обновить
                        600 ; повторить попытку
                        86400 ; истекает
                        3600 ) ; минимальный TTL 

Мы никогда не объясняли, какие значения были заключены в скобки. для.

Серийный номер применяется ко всем данным в зоне. Мы выбрали чтобы начать наш серийный номер с 1, логичное место для начала. DNS консоль автоматически увеличивает серийный номер в зоне Запись SOA всякий раз, когда вы вносите изменения в зону. Если у вас есть поддерживали файлы данных зоны вручную, возможно, вы закодировали дату в серийном номере — например, 2000102301. Этот формат ГГГГММДДНН, где ГГГГ — год, ММ — месяц, ДД — день, а NN — количество изменений данных зоны, которые день. К сожалению, вы не можете использовать это соглашение с DNS консоль. Он просто увеличивает серийный номер на единицу каждый раз, когда изменение внесено и не понимает кодировку даты.

Когда подчиненный сервер имен связывается с основным главным сервером для зоны data, он сначала запрашивает порядковый номер данных. Если серийный номер ведомого меньше, чем у основного, данные зоны подчиненного устройства устарели. В этом случае ведомый тянет новая копия зоны. Как вы могли догадаться, если вы когда-нибудь измените файлы данных зоны на первичном мастере вручную, вы должны увеличить серийный номер тоже. Обновление файлов данных зоны описано в главе 7.

Следующие четыре поля определяют различные временные интервалы в секундах:

обновить

Обновление interval сообщает подчиненному устройству, как часто следует проверять, соответствуют ли его данные дата. Чтобы дать вам представление о нагрузке на систему, которую вызывает эта функция, ведомое устройство будет делать один запрос SOA на зону за интервал обновления. значение по умолчанию, сгенерированное консолью DNS при создании зоны, один час, является достаточно агрессивным. Большинство пользователей допустят задержку половину рабочего дня на распространение таких вещей, как данные сервера имен когда они ждут, когда их новая рабочая станция заработает. Если вы оказываете однодневную услугу для своего сайта, рассмотрите возможность повышения этой значение до восьми часов. Если ваши данные не меняются очень часто, или если все ваши рабы разбросаны на большие расстояния (так как корень серверы имен), рассмотрите более длительное значение, например, 24 часа.

повторить

Если раб не удается связаться с первичным сервером (серверами) имен после периода обновления (хосты или хосты могут быть отключены), он начинает пытаться подключиться каждый повтора секунды. Интервал между попытками обычно короче, чем интервал обновления, но это не обязательно.

истекает

Если раб не удается связаться с первичным(и) сервером(ами) для истекает через секунды, срок действия данных подчиненного устройства истекает. Срок действия данных означает, что ведомое устройство перестает давать ответы о данные, потому что данные слишком старые, чтобы быть полезными. По существу, это поле говорит: в какой-то момент данные настолько устарели, что отсутствие данных лучше, чем устаревшие данные. Мы считаем, что Microsoft по умолчанию время истечения 86 400 секунд (24 часа) ужасно мало. Срок действия время порядка недели является обычным явлением, и интервал может быть дольше (до месяца), если у вас часто возникают проблемы с доступом к источник обновления. Время истечения всегда должно быть намного больше чем интервалы повтора и обновления; если время истечения меньше чем интервал обновления, срок действия ваших ведомых устройств истечет до пытается загрузить новые данные.

минимальный TTL

время жизни означает время жить. Это значение применяется ко всем ресурсам записи в файле данных зоны. Сервер имен предоставляет этот TTL в ответы на запросы, позволяя другим серверам кэшировать данные для TTL интервал. Если ваши данные не сильно меняются, вы можете рассмотреть используя минимальный TTL в несколько дней. Одна неделя — это самый длинный значение, имеющее смысл. Опять же, значение по умолчанию 3600 секунд (один час) очень мало, что мы не рекомендуем из-за объем DNS-трафика, который он вызывает.

Какие значения вы выберете для своей записи SOA, зависит от потребностей вашего сайта. Как правило, более длительное время вызывает меньшую нагрузку на ваш системы и удлинить распространение изменений; более короткие времена увеличить нагрузку на ваши системы и ускорить распространение изменения. Мы считаем, что следующие значения подходят для большинства сайтов; они также являются хорошей отправной точкой, если вы не уверены какие значения использовать:

 10800 ; Обновить 3 часа
        3600 ; Повторить через 1 час
     2592000 ; Срок действия 30 дней
       86400 ; Минимум TTL 1 день 

Последнее замечание о значениях TTL: консоль DNS отображает их в несколько загадочная мода. Взгляните на запись NS, которую мы добавили. на рис. 4-27. Обратите внимание на TTL, указанный как 0:1:0:0 . «Что за черт что?» ты спрашиваешь. Ну первое поле дни, потом часы, минуты и секунды. Поэтому вместо того, чтобы отображать значение в секундах и заставит вас заниматься математикой, консоль DNS позволяет вам указать TTL в (чуть) более удобный способ.

Получите DNS для Windows 2000, второе издание прямо сейчас с обучающей платформой O’Reilly.

члена O’Reilly знакомятся с книгами, живыми мероприятиями, курсами, созданными в зависимости от должности, и многим другим от O’Reilly и почти 200 ведущих издателей.

Начать бесплатную пробную версию

— настройка главного/подчиненного DNS в сравнении с rsync-серверами DNS

спросил 13 лет, 3 месяца назад

Изменено 13 лет, 2 месяца назад

Просмотрено 6к раз

В настоящее время в нашей корпоративной сети есть первичный и вторичный DNS-серверы. Они настраиваются по типу «главный/ведомый», где ведомый получает информацию о DNS от ведущего.

Я пытаюсь выяснить, в чем реальное преимущество установки master/slave вместо простой автоматической rsync между ними, чтобы сохранить одинаковые настройки DNS.

Может ли кто-нибудь пролить свет на это? Или это просто льготная вещь? Если это так, то кажется, что установка rsync будет намного проще в настройке, обслуживании и понимании.

• domain-name-system
• internal-dns
• bind

Конфигурация master/slave (также известная как «зональные передачи», AXFR или IXFR ) является стандартной конфигурация, используемая большинством DNS-серверов . Только по этой причине я бы порекомендовал это, хотя это сложно.

Хотя я рекомендую его из-за совместимости и простоты понимания другими администраторами, это не означает, что это технически лучший способ сделать это.

Daniel Bernstein (из djbdns / tinydns ) настоятельно предпочитает rsync и имеет эту таблицу, сравнивающую rsync с передачей зоны. rsync прекрасно работает с tinydns , но я никогда не пробовал с bind .

Если вы попробуете это, имейте в виду, что вы, вероятно, будете писать скрипт, который запускается cron . Другой администратор, который просматривает вашу конфигурацию DNS, не обязательно будет знать об этом или знать, где найти сценарий синхронизации. Напротив, обычная конфигурация передачи зоны находится прямо в ваших файлах зоны, что делает ее явной. Имеет ли это значение, зависит от того, со сколькими другими администраторами вы имеете дело и насколько вы ожидаете, что они будут информированы о вашей конфигурации DNS.

На самом деле тут многое происходит, но многое из этого может не иметь отношения к вашей ситуации.

Во-первых, использование отношений «главный/подчиненный» DNS позволяет легко выполнять репликацию между разнородными типами серверов. Я знаю, что синхронизировал основной сервер OS X Server (BIND?) с Windows DNS.

Это также позволяет указать, что вторичная система DNS может получать данные с разных первичных серверов для разных зон (и наоборот). Практический пример: раньше мы запускали собственную систему DNS и отдавали на аутсорсинг дополнительный вторичный DNS для надежности.

Расширить DNS-серверы таким образом тоже несложно. Вы просто добавляете новое подчиненное устройство в список вместо того, чтобы добавлять дополнительный сервер имен, настраивать дополнительную репликацию и т. д. Это делает процесс относительно автономным.

Есть несколько причин использовать AXFR / IXFR вместо rsync:

1. Это стандарт и работает во всех совместимых реализациях. Это позволяет вам смешивать серверы — возможно, если вам нужна устойчивость в случае проблем с безопасностью у одного из ваших поставщиков

2. Это быстро — изменения на главном сервере могут быть реплицированы на вторичные серверы в течение нескольких секунд, если вы используете механизм NOTIFY . (мастер сообщает вторичным серверам, что зона изменилась, а затем вторичные серверы могут получить изменения с помощью IXFR ).

3. Это надежно — нет никаких шансов, что ваш сервер каким-то образом получит наполовину скопированный файл и решит, что это целый файл.

FWIW, мы используем IXFR здесь на очень большая зона. Это «просто работает».

Предполагается, что BIND здесь.

• Если вы обновляете свои записи зоны, при перезагрузке мастер обычно уведомляет подчиненные об изменении. Затем ведомое устройство будет получать обновления.
• При использовании rsync обновления будут распространяться только при запуске rsync. Кроме того, тогда нужно сказать подчиненному, чтобы он перезагрузил изменения.

Мне кажется, что использование rsync не только создает больше проблем, но и создает больше проблем, которые могут привести к тому, что главный и подчиненный серверы не будут идти в ногу.

Похоже, что rsync и IXFR будут делать примерно одно и то же. Например, вы можете использовать rsync из bind9->bind9, но если вам нужно перейти из bind8->bind9 или bind->Microsoft, передача зоны все равно должна работать, несмотря на различия в бэкэнде. Плюс перехода только на rsync, как я вижу, заключается в том, что вы можете полностью отключить передачу зон, что хорошо с точки зрения безопасности.

Мы запускаем привязку с rsync с 1995 — Работает нормально — сегодня есть много причин для использования tinydns и/или переноса зон, но тогдашняя логика, и почему мы придерживаемся ее сегодня, заключается в том, что если один сервер каким-то образом был взломан, тогда нет истинного «основного» для него. повторить проблему другим.

Тем не менее, наличие основного внутреннего устройства для вашей локальной сети и ведомых устройств, доступных через Интернет, также решает проблему.

Мы запускаем rsync и перезагружаем через сценарии, а также некоторые проверки работоспособности. Если вы пойдете по этому пути, рассмотрите возможность добавления всех этих частей на случай, если что-то пойдет не так. Вы ДЕЙСТВИТЕЛЬНО не хотите, чтобы ваши DNS-серверы отключались или даже пропадали зоны.

Обычно я делаю то, что естественно в данной ситуации.

При использовании связывания, в зависимости от ситуации, я обычно запускаю 2 ведущих и несколько подчиненных устройств.

Изменения вносятся одним мастером; эти изменения проверяются, а затем синхронизируются с другим мастером. Этот мастер использует zoen-передачи для отправки зон на DNS-серверы, которые видят клиенты. Два других не афишируются. (первый мастер не является строго обязательным, но неплохо иметь ручную обезьяну) Мне также нравится иметь 2 копии конфигураций сервера и 2 копии файлов зон в правильном формате (вместо копии, которую вы получаете на подчиненный сервер). Необходимо следить за тем, чтобы сервер перезагружал зоны только 9 раз.0003 после rsync завершается.

Когда вы используете AD для DNS, вам не нужно беспокоиться об обмене зонами между серверами — протоколы AD волшебным образом заботятся о синхронизации всего.

PowerDNS предполагает, что вы будете использовать передачу зон или какой-либо механизм репликации базы данных для синхронизации.

TinyDNS может использовать передачу зон, но если вы передаете файлы внутри одной и той же организации, имеет смысл использовать что-то вроде rsync, потому что сервер tinydns делает перезагрузку зон безопасной и простой.

Наконец, и это наиболее важно, используйте передачу зон, если вы обмениваетесь зонами DNS с организациями, не находящимися под вашим непосредственным контролем. Например, у вашего интернет-провайдера обычно есть авторитетный сервер для клиентов. Этот сервер будет подчиненным сервером и получит зоны через передачу зон, независимо от того, какой тип DNS-сервера использует клиент. Точно так же, если я передам свой DNS провайдеру, такому как UltraDNS, я буду настаивать на том, чтобы иметь возможность выполнять передачу зон с их серверов, чтобы я мог покинуть их в любое время, обновив регистраторов, чтобы они использовали мои серверы вместо их серверов.