Меню Рубрики

Установка вторичного dns сервера

«GZpromo» продвижение сайтов

«DNS и BIND»

4. Установка BIND

Запуск вторичного DNS-сервера

Для надежности потребуется установить еще один DNS-сервер. Можно (рано или поздно многие так и поступают) установить более двух авторитетных DNS-серверов для локальных зон. Два DNS-сервера — это минимум, поскольку в случае, если есть только один сервер и он перестает работать, служба доменных имен для зоны перестает функционировать. Второй DNS-сервер делит нагрузку с первым сервером или принимает на себя всю нагрузку в случае аварии на первом сервере. Можно просто установить еще один основной DNS-сервер, но мы не рекомендуем этого делать. Вместо этого следует создать вторичный DNS-сервер. Позже, если вы не испугаетесь дополнительных усилий, которые нужно затратить, чтобы несколько первичных серверов могли дружно сосуществовать, то всегда сможете превратить вторичный сервер в первичный.

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

В чем разница между первичным DNS-сервером и вторичным? Коренное различие в том, откуда сервер получает свои данные. Первичный DNS-сервер читает данные из файлов данных зоны. Вторичный сервер загружает данные по сети, получая их от другого DNS-сервера. Этот процесс носит название передачи зоны.

Вторичный DNS-сервер может получать свои данные не только от первичного DNS-сервера, но и от другого вторичного сервера.

Большим преимуществом в использовании вторичных DNS-серверов является тот факт, что необходимо сопровождать единственный набор файлов данных для зоны, а именно — набор файлов для первичного сервера. Нет необходимости беспокоиться о синхронизации файлов нескольких DNS-серверов; вторичные DNS-серверы синхронизируются автоматически. Минус в том, что вторичный сервер не синхронизируется каждое мгновение, но проверяет актуальность своих данных через определенные интервалы времени. Интервал опроса — одно из тех чисел в SOA-записи, про которые мы еще ничего не рассказывали. (BIND версий 8 и 9 реализует механизм ускорения распределения зональных данных, который будет описан позже.)

Вторичный DNS-сервер не должен получать по сети все свои данные: «лишние» файлы db.cache и db.127.0.0 точно такие же, как на основном сервере, так что имеет смысл хранить их локальную копию. Это означает, что вторичный DNS-сервер является первичным сервером для 0.0.127.in-addr.arpa. Конечно, возможно сделать вторичный сервер вторичным и для 0.0.127.in-addr.arpa, но данные этой зоны никогда не изменяются, так что особой разницы нет.

Установка

Чтобы установить вторичный DNS-сервер, потребуется создать каталог для файлов данных зоны на узле, который будет являться вторичным сервером (например, /var/named) и скопировать в него файлы /etc/named. conf, db.cache и db.127.0.0:

# rcp /etc/named.conf host:/etc
# rcp db.cache db.127.0.0 host:db-file-directory

Потребуется отредактировать файл /etc/named.conf на узле вторичного DNS-сервера. Замените каждое вхождение ключевого слова master на slave, за исключением относящегося к зоне 0.0.127.in-addr.arpa, и добавьте строку masters, указывающую IP-адрес первичного сервера, который и будет основным сервером DNS для этих зон. Если исходная строка в файле настройки выглядела так:

Так мы говорим DNS-серверу, что он является вторичным для зоны movie.edu и что он должен реагировать на изменения этой зоны, хранимой DNS-сервером с IP-адресом 192.249.249.3. Вторичный DNS- сервер будет хранить резервную копию этой зоны в локальном файле bak.movie.edu.

Вторичный DNS-сервер Университета кинематографии будет размещен на узле wormhole.movie.edu. Напоминаем, что файл настройки на узле toystory.movie.edu (на котором размещается основной сервер) выглядит так:

Мы копируем файлы /etc/named.conf, db.cache и db.127.0.0 на машину wormhole.movie.edu, а затем редактируем файл настройки, как описано выше. Файл настройки на узле wormhole.movie.edu выглядит теперь следующим образом:

Он инструктирует DNS-сервер, работающий на узле wormhole.movie.edu, загружать movie.edu, 249.249.192.in-addr.arpa и 253.253.192.inaddr. arpa по сети, получая информацию от DNS-сервера с адресом 192.249.249.3 (toystory.movie.edu). Помимо этого сервер сохраняет резервную копию этих файлов в каталоге /var/named. Возможно, комуто будет удобнее размещать резервные копии файлов в отдельном подкаталоге. Мы добавляем к файлам уникальный префикс (bak), поскольку иногда появляется необходимость вручную удалить все резервные копии. Удобно, когда уже по имени видно, что файлы являются резервными копиями, и редактировать их не имеет смысла. Позже мы обсудим резервное копирование файлов подробнее.

Теперь запустим вторичный DNS-сервер. Следует проверить наличие сообщений об ошибках в log-файле демона syslog — точно так же, как это делалось для основного сервера. Как и для первичного сервера, команда запуска:

Помимо тестов, уже описанных для первичного DNS-сервера, вторичный следует подвергнуть еще одному. Необходимо проверить, были ли созданы резервные копии файлов. Вскоре после того, как вторичный сервер был запущен на узле wormhole.movie.edu, мы обнаружили в каталоге var/named файлы bak.movie.edu, bak.192.249.249 и bak.192.253.253. Это означает, что вторичный сервер успешно получил зону от основного сервера и сохранил ее резервную копию.

Чтобы завершить установку вторичного DNS-сервера, попробуйте произвести поиск для тех же доменных имен, которые использовались при тестировании первичного сервера. На этот раз следует выполнять nslookup на узле, на котором работает вторичный DNS-сервер, чтобы именно этот сервер получал запросы. Если вторичный DNS-сервер работает как должен, добавьте соответствующие строки в загрузочные файлы системы, чтобы при загрузке системы DNS-сервер стартовал автоматически, а также воспользуйтесь командой hostname(1) для установки доменного имени.

Резервные копии файлов

Дополнительные DNS-серверы не обязаны сохранять резервную копию зональных данных. Если существует резервная копия, вторичный DNS-сервер читает ее при запуске, а позже проверяет первичный мастер-сервер DNS на наличие более свежей копии вместо того, чтобы сразу загружать копию зоны с основного сервера. Если на основном контрольном сервере имен доступна более свежая копия, вторичный сервер получает ее и сохраняет в качестве резервной копии.

Читайте также:  Установка бетонного блока расценка

Зачем нужна резервная копия? Предположим, первичный DNS-мастер-сервер недоступен на момент запуска вторичного сервера. В таком случае вторичный сервер не сможет произвести передачу зоны и не будет функционировать в качестве DNS-сервера для зоны, пока основной сервер не станет доступен. В случае наличия резервной копии вторичный сервер обладает информацией, хотя она может быть немного устаревшей. И поскольку при использовании резервного копирования вторичный DNS-сервер становится менее зависим от основного, он более надежен в работе.

Чтобы избежать создания резервных копий, удалите строку file из файла настройки. При этом мы советуем настраивать дополнительные DNS-серверы таким образом, чтобы они создавали резервные копии. Сохранение резервных копий файлов данных зоны ничего не стоит, зато недешево обойдется ситуация, когда резервная копия спасла бы положение, но ее нет.

Значения SOA

movie.edu. IN SOA toystory.movie.edu. al.movie.edu. (

1 ; Порядковый номер
3h ; Обновление через 3 часа
1h ; Повторение попытки через 1 час
1w ; Устаревание через 1 неделю
1h ) ; Отрицательное TTL в 1 час

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

Порядковый номер относится ко всем данным в пределах зоны. Мы начали с единицы, что вполне логично. Но многие люди находят более удобным использовать в качестве порядкового номера даты, к примеру 2005012301. Это дата в формате ГГГГММДДNN, где ГГГГ — год, ММ — месяц года, ДД — день месяца, а NN — счетчик числа изменений зональных данных в этот день. Порядок полей менять нельзя, поскольку только этот порядок приводит к увеличению значения порядкового номера при смене даты. Это очень важно: какой бы формат ни использовался, порядковый номер должен увеличиваться при обновлении данных зоны.

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

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

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

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

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

TTL — это время жизни (time to live). Это значение относится ко всем отрицательным ответам DNS-серверов, авторитетных для данной зоны.

Для версий BIND более старых, чем 8.2, последнее поле SOA-записи определяет оба значения — стандартное (по умолчанию) и отрицательное значение времени жизни информации для зоны.

Те из читателей, кто знаком с предыдущими изданиями этой книги, могут заметить, что изменился формат значений полей в SOA-записях. Когда-то BIND понимал значения, выраженные в секундах, только для четырех описанных полей. (В результате выросло целое поколение администраторов, которые знают, что в неделе 60 8400 секунд.) Теперь при работе со всеми серверами кроме самого старого (BIND 4.8.3) можно указывать значения в других единицах измерения, причем не только в SOA-записи, но и в качестве аргумента управляющего оператора TTL, что мы видели выше по тексту. К примеру, задать трехчасовой интервал обновления можно значениями 3h, 180m и даже 2h60m. Дни обозначаются буквой d, а недели — буквой w.

Корректные значения SOA-записи зависят от конкретного случая. В целом, более длительные интервалы времени снижают нагрузку на DNS-серверы и замедляют распространение изменений, более короткие увеличивают нагрузку и ускоряют распространение изменений. Значения, которые мы используем в этой книге, вполне подойдут для большинства установок. Документ RFC 1537 рекомендует следующие значения для DNS-серверов высшего уровня:

Читайте также:  Установка блок розеток в гипсокартоне

Обновление 24 часа
Повторение попытки 2 часа
Устаревание 30 дней
Стандартное TTL 4 дня

Существует одна особенность реализации, о которой следует знать. Версии BIND, которые предшествовали версии 4.8.3, перестают отвечать на запросы в процессе загрузки зоны. В результате пакет BIND был модифицирован с целью распределения загрузок зоны и сокращения интервалов недоступности. Поэтому, даже в случае когда установлены короткие интервалы обновления, вторичные DNS-серверы могут производить синхронизацию реже, чем предписано этими интервалами. BIND пытается произвести загрузку зоны определенное число раз, а затем делает 15-минутный перерыв, прежде чем повторить попытки.

Итак, мы рассказали о том, как DNS-серверы обновляют свои данные. но в BIND 8 и 9 механизм распространения данных зоны другой! Опрос основных серверов все еще доступен, но в BIND 8 и 9 существует механизм уведомления об изменениях в зональных данных. Если первичный мастер-сервер и все вторичные являются серверами пакета BIND версии 8 или 9, первичный сервер DNS уведомляет вторичные серверы об изменениях зоны в течение пятнадцати минут после загрузки новой копии этой зоны. Уведомление заставляет вторичный сервер сократить интервал обновления и попытаться загрузить зону немедленно. Более подробно мы обсудим этот механизм в главе 10.

Несколько мастер-серверов

Существуют ли другие способы сделать работу вторичных DNS-серверов более надежной? Разумеется: можно указать до десяти IP-адресов мастер-серверов. В файле настройки следует добавить эти адреса после первого IP-адреса, используя точку с запятой в качестве разделителя:

В случае BIND 9.3 и более поздних версий вы можете назначить имя списку IP-адресов мастер-серверов, а затем просто ссылаться на это имя. Это позволяет избежать повторения IP-адресов для каждой зоны.

Вторичный сервер будет перебирать мастер-серверы из списка, пока не получит ответ. Вплоть до BIND версии 8.1.2 вторичный DNS-сервер всегда производил передачу зоны с первого ответившего мастер-сервера, если данные на этом мастере имели больший порядковый номер. Последующие DNS-серверы опрашивались только в случае отсутствия ответов от предшествующих. Начиная с BIND версии 8.2 вторичный сервер опрашивает все перечисленные мастер-серверы DNS и производит передачу зоны с сервера, данные которого имеют наибольший порядковый номер. Если таких серверов несколько, вторичный сервер получает данные зоны от первого (в порядке чтения списка) из этих серверов.

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

источник

Настройка дополнительного DNS-сервера в Windows Server

Дополнительные серверы обеспечивают отказоустойчивость DNS-службы сети. Если вы используете полную интеграцию с Active Directory, настраивать дополнительные серверы вам не нужно. Достаточно запустить службу DNS на нескольких контроллерах домена, и Active Directory будет реплицировать информацию DNS на все контроллеры. При использовании частичной интеграции следует настроить дополнительные серверы, чтобы уменьшить нагрузку на основной сервер. В небольшой или средней сети можно использовать в качестве дополнительных серверов DNS-серверы поставщика услуг Интернет. Свяжитесь с провайдером, чтобы узнать подробности.

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

Чтобы установить дополнительные серверы для повышения отказоустойчивости и балансировки нагрузки, выполните следующие действия:

1. Откройте консоль Диспетчер DNS (DNS Manager) и подключитесь к нужному серверу.

2. Щелкните правой кнопкой элемент сервера и выберите команду Создать новую зону (New Zone). Откроется Мастер создания новой зоны (New Zone Wizard). Щелкните Далее (Next).

3. На странице Тип зоны (Zone Туре) установите переключатель Дополнительная зона (Secondary Zone). Щелкните Далее (Next).

4. На дополнительных серверах используются зоны как прямого, так и обратного просмотра. В первую очередь создаются зоны прямого просмотра, поэтому установите переключатель Зона прямого просмотра (Forward Lookup Zone) и щелкните Далее (Next).

5. Введите полное DNS-имя зоны и щелкните Далее (Next).

6. В списке Основные серверы (Master Servers) введите ІР-адрес основного сервера зоны и нажмите Enter. Мастер попытается проверить сервер. Если произошла ошибка, убедитесь, что сервер подключен к сети и вы ввели правильный ІР-адрес. Если вы хотите скопировать данные зоны ИЗ других серверов на случай недоступности первого сервера, повторите этот шаг.

7. Щелкните Далее (Next) и Готово (Finish). В большой сети вам, возможно, потребуется настройка зон обратного просмотра на дополнительных серверах. Этот способ мы подробнее опишем в следующих постах…

источник

Настройка DNS-сервера на Windows Server 2012 и старше

DNS (Domain Name System, Система Доменных имен) – система, позволяющая преобразовать доменное имя в IP-адрес сервера и наоборот.

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

Настройка сетевого адаптера для DNS-сервера

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

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

Читайте также:  Установка after effect cs5

Наведя курсор на значок сети в системном трее, можно вызвать всплывающую подсказку с краткими сведениями о сетях. Из примера выше видно, что присоединённая сеть это Network 3.

Далее предстоит проделать цепочку действий:

  • Нажать правой клавишей мыши Пуск, в выпадающем меню выбрать пункт Сетевые подключения;
  • Правой кнопкой мыши нажать на необходимый сетевой адаптер, в меню выбрать Свойства;
  • В окне свойств выбрать IPv4 и нажать на кнопку Свойства;
  • Заполнить соответствующие поля необходимыми данными:

Здесь в качестве предпочитаемого DNS-сервера машина назначена сама себе, альтернативным назначен dns.google [8.8.8.8].

Установка роли DNS-сервера

Для установки дополнительных ролей на сервер используется Мастер Добавления Ролей и Компонентов, который можно найти в Диспетчере Сервера.

На верхней навигационной панели Диспетчера сервера справа откройте меню Управление, выберите опцию Добавить Роли и Компоненты:

Откроется окно Мастера, в котором рекомендуют убедиться что:

1. Учётная запись администратора защищена надёжным паролем.

2. Настроены сетевые параметры, такие как статические IP-адреса.

3. Установлены новейшие обновления безопасности из центра обновления Windows.

Убедившись, что все условия выполнены, нажимайте Далее;

Выберите Установку ролей и компонентов и нажмите Далее:

Выберите необходимый сервер из пула серверов и нажмите Далее:

Отметьте чек-боксом роль DNS-сервер и перейдите Далее:

Проверьте список компонентов для установки, подтвердите нажатием кнопки Добавить компоненты:

Оставьте список компонентов без изменений, нажмите Далее:

Прочитайте информацию и нажмите Далее:

В последний раз проверьте конфигурацию установки и подтвердите решение нажатием кнопки Установить:

Финальное окно Мастера сообщит, что установка прошла успешно, Мастер установки можно закрыть:

Создание зон прямого и обратного просмотра

Доменная зона — совокупность доменных имён в пределах конкретного домена.

Зоны прямого просмотра предназначены для сопоставления доменного имени с IP-адресом.

Зоны обратного просмотра работают в противоположную сторону и сопоставляют IP-адрес с доменным именем.

Создание зон и управление ими осуществляется при помощи Диспетчера DNS.

Перейти к нему можно в правой части верхней навигационной панели, выбрав меню Средства и в выпадающем списке пункт DNS:

Создание зоны прямого просмотра

  • Выделите каталог Зоны Прямого Просмотра, запустите Мастер Создания Новой Зоны с помощью кнопки Новая зона на панели инструментов сверху:

  • Откроется окно Мастера с приветствием, нажмите Далее:

  • Из предложенных вариантов выберите Основная зона и перейдите Далее:

  • Укажите имя зоны и нажмите Далее:

  • При необходимости поменяйте название будущего файла зоны и перейдите Далее:

  • Выберите, разрешить динамические обновления или нет. Разрешать не рекомендуется в силу значимой уязвимости. Перейдите Далее:

  • Проверьте правильность выбранной конфигурации и завершите настройку, нажав кнопку Готово:

Создание зоны обратного просмотра

  • Выделите в Диспетчере DNS каталог Зоны Обратного Просмотра и нажатием кнопки Новая зона на панели инструментов сверху запустите Мастер Создания Новой Зоны:

  • Выберите тип Основная Зона, перейдите Далее:

  • Выберите назначение для адресов IPv4, нажмите Далее:

  • Укажите идентификатор сети (первые три октета сетевого адреса) и следуйте Далее:

  • При необходимости поменяйте название будущего файла зоны и перейдите Далее:

  • Выберите, разрешить динамические обновления или нет. Разрешать не рекомендуется в силу значимой уязвимости. Перейдите Далее:

  • Проверьте правильность выбранной конфигурации и завершите настройку, нажав кнопку Готово:

Создание A-записи

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

Ресурсная запись — единица хранения и передачи информации в DNS, заключает в себе сведения о соответствии какого-либо имени с определёнными служебными данными.

Запись A — запись, позволяющая по доменному имени узнать IP-адрес.

Запись PTR — запись, обратная A записи.

  • В Диспетчере DNS выберите каталог созданной ранее зоны внутри каталога Зон Прямого Просмотра. В правой части Диспетчера, где отображается содержимое каталогов, правой кнопки мыши вызовите выпадающее меню и запустите команду «Создать узел (A или AAAA)…»:

  • Откроется окно создания Нового Узла, где понадобится вписать в соответствующие поля имя узла (без доменной части, в качестве доменной части используется название настраиваемой зоны) и IP-адрес. Здесь же имеется чек-бокс Создать соответствующую PTR-запись — чтобы проверить работу обеих зон (прямой и обратной), чек-бокс должен быть активирован:

Если поле имени остается пустым, указанный адрес будет связан с именем доменной зоны.

  • Также можно добавить записи для других серверов:

  • Добавив все необходимые узлы, нажмите Готово.

Проверка

  • Откройте командную строку (cmd) или PowerShell и запустите команду nslookup:

Из вывода команды видно, что по умолчанию используется DNS-сервер example-2012.com с адресом 10.0.1.6.

Чтобы окончательно убедиться, что прямая и обратная зоны работают как положено, можно отправить два запроса:

  • Запрос по домену;
  • Запрос по IP-адресу:

В примере получены подходящие ответы по обоим запросам.

  • Можно попробовать отправить запрос на какой-нибудь внешний ресурс:

В дополнение к имени домена и адресам появилась строчка «Non-authoritative answer», это значит, что наш DNS-сервер не обладает необходимой полнотой информации по запрашиваемой зоне, а информация выведенная ниже, хоть и получена от авторитетного сервера, но сама в таком случае не является авторитетной.

Для сравнения все те же запросы выполнены на сервере, где не были настроены прямая и обратная зоны:

Здесь машина сама себе назначена предпочитаемым DNS-сервером. Доменное имя DNS-сервера отображается как неопознанное, поскольку нигде нет ресурсных записей для IP-адреса (10.0.1.7). По этой же причине запрос 2 возвращает ошибку (Non-existent domain).

источник