Перенос зон DNS — настройка второго DNS сервера в домене

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

Настройка основной зоны DNS

1. Открываем консоль диспетчера DNS: комбинация клавиш Win+R и вводим команду dnsmgmt.msc

2. Выбираем сервер и переходим в «Зоны прямого доступа».

3. Заходим в свойства нужной зоны и переходим на вкладку

4. Ставим галочку «Разрешить передачу зон» и выбираем пункт «Только на серверы из этого списка». Нажимаем кнопку «Изменить».

5. Указываем ip-адрес второго сервера DNS

Настройка дополнительной зоны DNS для переноса записей

Переходим к настройке зон DNS на стором сервере для выполнения переноса зон.

1. В консоле диспетчера DNS так же переходим в «Зоны прямого просмотра» и создаем новую зону.

2. В мастере создания новой зоны выбираем пункт «Дополнительная зона»

3. Указываем имя зоны к которой хотим присоединиться

4.Указываем основной DNS-сервер с которого необходимо скопировать зону

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

soft-setup.ru

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

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

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

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

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

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

Наведя курсор на значок сети в системном трее, можно вызвать всплывающую подсказку с краткими сведениями о сетях. Из примера выше видно, что присоединённая сеть это 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-запись — чтобы проверить работу обеих зон (прямой и обратной), чек-бокс должен быть активирован:

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

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

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

Проверка

• Проверьте изменения в каталогах обеих зон (на примере ниже в обеих зонах появилось по 2 новых записи):

• Откройте командную строку (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).

serverspace.by

Настройка DNS сервера на Windows Server 2008

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

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

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

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

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

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

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

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

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

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

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

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

• В левой части окна Диспетчера сервера откройте раздел Роли, после чего в правой части окна отобразится команда Добавить Роли:

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

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

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

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

• Убедившись, что все условия выполнены, нажмите Далее;
• Отметьте чек-боксом роль DNS-сервер и перейдите Далее:

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

• Убедитесь, что выбор сделан правильно, и подтвердите нажатием кнопки Установить:

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

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

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

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

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

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

Данный инструмент открывается из навигационного дерева Диспетчера Сервера:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проверка

• Проверьте изменения в каталогах обеих зон (на примере ниже в обеих зонах появилось по 2 новых записи):

• Откройте командную строку (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).

serverspace.by

Как настроить DNS сервер в windows server 2012R2-2 часть. Настройка дополнительной зоны. Создание и настройка заглушки

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

Настройка dns windows server 2012 r2

Настройку dns windows server 2012 r2 мы начнем с открывания оснастки Диспетчер DNS. Как видите, contoso.com еще пустая.

Как настроить DNS сервер в windows server 2012R2-2 часть—08

Для этого идем на ваш Контроллер домена, у меня это dc. Выбираем свойства нужной зоны

Как настроить DNS сервер в windows server 2012R2-2 часть—09

Идем на вкладку сервера имен. Нажимаем Добавить

Как настроить DNS сервер в windows server 2012R2-2 часть—11

пишем имя нужного сервера, у меня это sccm

Как настроить DNS сервер в windows server 2012R2-2 часть—12

В итоге у меня получился вот такой список.

Как настроить DNS сервер в windows server 2012R2-2 часть—13

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

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

Передача зон, по сути, представляет собой извлечение данных, инициируемое в дополнительных зонах, копирование данных главной зоны, которая сама по себе может быть основной или еще одной дополнительной зоной. Главной зоне необязательно даже быть стандартной по отношению к дополнительной зоне — вы можете отконфигурировать дополнительную зону для основной зоны, интегрированной в Active Directory. К примеру, у вас есть два сайта — один в Нью-Йорке, другой в Лос-Анджелесе, причем каждый сайт принадлежит  отдельному домену Active Directory. В каждом домене можно обеспечить разрешение имен для противоположного домена, не устанавливая новый контроллер домена и не управляя трафиком репликации между двумя сайтами.

Включение передачи зон

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

■ По истечении интервала обновления начальной записи SOA основной зоны.

■ При загрузке дополнительной зоны сервером.

■ В результате изменения конфигурации основной зоны, если эта зона настроена для уведомления дополнительной зоны об обновлениях.

По умолчанию передача для всех зон отключена. Ее нужно включить на вкладке Передача зон (Zone Transfers) окна свойств зоны. Установив флажок разрешения передачи зон, можно выбрать одни из трех параметров передачи.

■ На любой сервер (To Any Server) Этот параметр обеспечивает минимальную безопасность. Поскольку передача зоны представляет собой копирование данных зоны, этот параметр позволяет кому угодно с сетевым доступом к DNS-серверу просмотреть содержимое зоны, включая имена всех серверов и компьютеров с их IP-адресами. Поэтому данный параметр следует  использовать только в частных сетях с высоким уровнем безопасности.

■ Только на серверы, перечисленные на странице серверов зон (Only To ServersListed On The Name Servers Tab) Этот параметр позволяет выполнять передачу зон с записью NS только на те дополнительные DNS-серверы, которые полномочны для данных зон.

■ Только на серверы из этого списка (Only To The Following Servers) Этот параметр позволяет указать список дополнительных серверов, на которые будет выполняться передача зон. Для этих дополнительных серверов не требуется идентификация с помощью записи NS в зоне.

Настройка уведомлений

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

Для настройки уведомлений на вкладке Передача зон (Zone Transfers) щелкните кнопку Уведомить (Notify). Откроется диалоговое окно Уведомление  (Notify), где можно указать дополнительные серверы, которые будут оповещаться при обновлении зоны на локальном главном сервере.

По умолчанию при включении передачи зон все серверы, перечисленные на вкладке Серверы имен (Name Servers), автоматически уведомляются об обновлениях зоны.

Обновление дополнительной зоны вручную

Если щелкнуть дополнительную зону правой кнопкой мыши на вашем DNS, у меня это vcenter, откроется контекстное меню, в котором можно использовать следующие операции для обновления зоны.

■ Перезагрузка (Reload)

Перезагружается дополнительная зона из локального хранилища.

■ Передать зону с основного сервера (Transfer From Master)

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

■ Перезагрузить повторно зону с основного сервера (Reload From Master)

Выполняется передача зоны с главного сервера дополнительной зоны независимо от серийного номера в записи SOA дополнительной зоны.

Выбираем Передать зону с основного сервера

Как настроить DNS сервер в windows server 2012R2-2 часть—14

Как видим если нажать F5 зона передалась

Как настроить DNS сервер в windows server 2012R2-2 часть—15

Все записи прилетели, единственное они не редактируемые.

Как настроить DNS сервер в windows server 2012R2-2 часть—16

Иногда может не получиться, тогда перезапустите службу на сервере DNS где дополнительная зона, сто процентов проканает.

Зона-заглушка

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

Зоны-заглушки можно использовать в следующих целях:

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

Существует два списка DNS-серверов, участвующих в загрузке и поддержке зоны-заглушки:

• Список главных серверов, из которого DNS-сервер загружает и обновляет зону-заглушку. Главный сервер может быть главным или дополнительным DNS-сервером для зоны. В обоих случаях он будет располагать полным списком DNS-серверов для зоны.
• Список полномочных DNS-серверов для зоны. Список содержится в зоне-заглушке с использованием записей ресурсов сервера имен (NS).

Создадим зону заглушку или как еще ее называют stub zone.

Щелкаем правым кликом по зоны прямого просмотра и выбираем создать

Как настроить DNS сервер в windows server 2012R2-2 часть—17

Откроется мастер создания зоны.

Как настроить DNS сервер в windows server 2012R2-2 часть—18

Выбираем зона заглушка

Как настроить DNS сервер в windows server 2012R2-2 часть—19

задаем имя зоны

Как настроить DNS сервер в windows server 2012R2-2 часть—20

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

Как настроить DNS сервер в windows server 2012R2-2 часть—21

Пишем имя главного dns с которого будем запрашивать зону

Как настроить DNS сервер в windows server 2012R2-2 часть—22

Готово

Как настроить DNS сервер в windows server 2012R2-2 часть—23

Видим что файл зоны заглушки лежим в папке windows\system32\dns

Как настроить DNS сервер в windows server 2012R2-2 часть—24

Файл кстати открывается любым текстовым редактором.

Как настроить DNS сервер в windows server 2012R2-2 часть—25

Пример зоны-заглушки

Предположим, вы работаете администратором DNS-сервера Dns1.microsoft.com, который уполномочен для зоны Microsoft.com. Ваша компания имеет дочерний домен Active Directory с именем India.microsoft.com, для которого выполняется делегирование. При начальном делегировании дочерняя зона, интегрированная иActive Directory, содержит только два полномочных DNS-сервера — 192.168.2.1 и 192.168.2.2. Позже администраторы домена India.microsoft.com развертывают дополнительные контроллеры домена и устанавливают роль DNS-сервер (DNSServer) на новых контроллерах. Однако администраторы не уведомили вас о том, что добавили полномочные DNS-серверы на свой домен. В результате на сервереDns1.microsoft.com оказались не отконфигурированными записи новых DNS-серверов, уполномоченных для домена lndia.microsoft.com, и запросы продолжают пересылаться лишь на два DNS-сервера, заданный в начальном делегировании.

Эту проблему можно устранить, создав зону-заглушку на сервере Dns1. microsoft.com для домена India.microsoft.com. С помощью новой зоны-заглушки компьютер Dns1 посредством передачи зон изучает новые серверы имен, уполномоченные для родительской зоны India.microsoft.com. Таким образом, сервер Dns1 сможет направлять запросы пространства имен Inclia.microsoft.com на все полномочные DNS-серверы дочерней зоны.

В следующей статье мы поговорим про дополнительные настройки и вкладки DNS сервера windows server 2008R2-2012R2

pyatilistnik.org

делаем правильно / Конференции Олега Бунина (Онтико) corporate blog / Habr

Представляем вашему вниманию очень эмоциональный рассказ Льва Николаева (@maniaque) о том, как надо настраивать DNS и особенно, как делать не надо. Вот прямо после каждого пункта можете мысленно добавлять: «Пожалуйста, не делайте этого!» В своем докладе Лев так и говорит.

Статья будет состоять из трех частей:

1. Как сделать резольвер (unbound, bind)

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

2. Как держать зоны (PowerDNS)

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

3. Как взболтать, но не смешивать (PowerDNS + unbound)

О спикере: Три года назад Лев Николаев пришел в компанию Макснет, в которой DNS развивался как раз не совсем правильно. Был bind и текстовые файлы с зонами; руки чесались навести порядок. В основе статьи доклад на Root Conf 2017, в ходе которого Лев делится с сообществом своим ассортиментом граблей.

Делаем резольвер

Резольвер нужен тем организациям, у которых либо нет провайдерского резольвера, либо которым он уже начинает мешать (от вас льется столько запросов, что резольвер не успевает отвечать или же лимитирует вас). От ЦОД или провайдера в принципе ждут наличия своего производительного резольвера.

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

Выбор софта для резольвера

По большому счету, здесь всего 2 варианта:

1. Вы можете использовать bind;
2. Вы можете использовать unbound.

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

В отношении резольвера я не пытаюсь вас склонить к выбору какого-то конкретного софта, потому что на сегодня резольвер — это в первую очередь некие реализуемые фичи, а не конкретный софт. Вы можете использовать bind или unbound, или что угодно еще, если оно будет отвечать тем вещам, про которые я сейчас расскажу.

Привет убунтоводам!

Если вы любите Ubuntu, как мы, и используете ее в продакшне, вам придется немножко повелосипедить. Как известно, unbound должен стартовать вместе с системой. В 16.04 перешли на systemd, но, естественно, юнит написать забыли. И когда генератор пытается его сгенерировать автоматически из SysV-скрипта, получается полное безобразие. Не вздумайте это выкатывать в продакшн — я это сделал и оставил 30 000 абонентов без DNS на полчаса. Благо, это было ночью.

Пишите юнит! Или возьмите у меня, в конце будет адрес репозитория. Это касается только тех, кто с Ubuntu, но, например, в Debian что-то близкое должно быть.

Что должно быть в резольвере?

5 вещей, которые нужно сделать в своем резольвере.

1. Никаких форвардов к Яндексу или Google

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

Иногда бывает, что даже заветные 4 восьмерки недоступны, соответственно, у вас тоже будут проблемы. Абсолютно то же самое касается и Яндекса.

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

2. SO_REUSEPORT

Эта опция реально ускоряет жизнь, но требует, чтобы у вас было ядро, как минимум, версии 3.9. Если среди вас есть любители ядер 2.6. (моябабушкаизRedHat), закопайте его, пожалуйста. Опция SO_REUSEPORT позволяет нескольким процессам одновременно биндить один порт (у них должен быть одинаковый UID, чтобы порт не «угнать»), но ее приятственность в другом — нагрузка распределяется на эти потоки равномерно. Для DNS это подходит идеально, и вы на самом деле увидите прирост производительности, просто перейдя на современное ядро.

SO_REUSEPORT есть и в bind, и в unbound. В bind он включен из коробки, в unbound его надо отдельно включать, потому что unbound пытается быть максимально совместимым, иногда в ущерб производительности.

3. Prefetch

Это странная опция. Она действительно помогает в том смысле, что она немножко не уважает TTL. Когда мы идем к авторитетному серверу и спрашиваем у него какую-то запись, у нее есть TTL — это то время, в течение которого к нему можно за обновлением не ходить. Unbound и bind идут за обновленным содержимым этой записи раньше, чем TTL реально истек.

Но есть две особенности. Вы получите прирост в исходящем трафике процентов на 10. Хотя на самом деле в целом резольверы с трудом могут генерировать вообще много трафика, поэтому вряд ли это вас будет волновать. Второй момент — с короткими TTL (например, в минуту) с Prefetch никакой особой пользы не получится, но так как для ru-сегмента короткий TTL пока еще фантастика, в принципе может отлично сработать.

4. Expired

Этой опции в bind я не нашел, но в unbound она есть и позволяет возвращать просроченную запись с нулевым TTL, а в фоне пытается получить свежую у авторитетных серверов. Это хорошо помогает от крупных падений, например, пользователи могли бы даже и не заметить недавнего падения Dyn, если эта опция была бы массово включена. Но ее не все знают, не все любят и не все включают.

5. DNSSEC

DNSSEC есть в 2 разных ипостасях — в простой и в сложной:

• Простой, когда вы просто валидируете запись, если DNSSEC у домена включен.
• Сложной, когда вы сами для своего домена делаете подпись DNSSEC и пр.

В простом варианте оно работает автоматически. Просто, если есть DNSSEC, надо его проверять, и при нарушениях не отдавать результат запроса. На сегодня это важно, потому что TTL записей стремятся к 0, т. е. существует определенная вероятность попытки отравления кэша DNS.

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

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

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

Мелочи жизни

1. Перестаньте отвечать на ANY

Если вы делаете резольвер, перестаньте отвечать на запросы ANY потому, что это вид запроса, который на самом деле толком не стандартизован и используется на 99% всякими замечательными вирусами.

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

iptables -A INPUT -p udp --dport 53 -m string --hex-string "|0000ff0001|" --algo bm -j DROP

2. Rate-limit

Используйте ограничение на количество запросов в секунду, если Вы не закрыты извне. Мой резольвер по целому ряду причин пришлось открыть всему миру, поэтому практически первое, что я сделал — это ограничил количество запросов в секунду извне. Если вы не можете закрыть ваш резольвер для клиентов снаружи, то хотя бы лимитируйте их. Лимит поставьте по вкусу, например, у меня 70 запросов в секунду.

[здесь -j ACCEPT для всех тех, от кого закрываться не надо]
iptables -A INPUT -p udp --dport 53 -m state --state NEW -m recent …
--set --name DNSQF --rsource
--update --seconds 1 --hitcount 70 --name DNSQF --rsource -j DROP

3. Для unbound хорошо interface-automatic: yes

Третья приятная мелочь. Обычно, в сети делается не один резольвер, и иногда хочется делать между ними failover, но, естественно, не при помощи самого резольвера. Надо failover делать методами маршрутизации и у unbound есть отличная опция interface-automatic: yes. Она говорит: «Если запрос ко мне попал в принципе, мне плевать, кому он был предназначен, я отвечу на него». С этой опцией очень удобно, если нужно, на unbound заворачивать трафик соседнего резольвера.

Что мониторить?

Это типичная картинка с прода. Мы здесь видим, что количество запросов достигло 300 000 запросов, и это не в минуту и не в секунду, у меня статистика снимается каждые 5 минут, т. е. на самом деле мелочь.

Таким образом, мониторить количество запросов обязательно нужно, т. к. если вы не можете их измерять, вы не можете их контролировать. Еще нужно мониторить виды запросов. В примере ниже хорошо видно: бирюзовая полоска — это PTR-запросы, и надо разбираться, почему их так много и откуда они берутся.

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

Это делается достаточно просто — вы по cron дергаете статистику unbound, а потом оттуда (мы в Zabbix юзер-параметром) забираете то, что нужно.

Виды ответов тоже обязательно надо мониторить. На картинке выше типичный пример DNS Water Torture, т. е. ботнет внутри вашей сети запрашивает несуществующие адреса поддомены атакуемого домена. В результате он получает ответ Nodata (красный цвет), в примере доходило до 25 000 таких запросов в пике.

Цель при этом: заколебать до смерти Name-сервер атакуемого домена, чтобы он устал отвечать и на легитимные запросы. А как только вы начинаете мониторить виды ответов, то начинаете видеть, насколько внутри вашей сети активны ботнеты.

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

Другая проблема — что с этим делать потом, но это не сегодняшняя тематика.

Ваш лучший друг — dnstop

Это очень удобная команда, чтобы понять, кто и что запрашивает, если случилась атака и что-то пошло не так. Обычно, её запускают без параметров, но это неправильно.

dnstop <интерфейс> -i <наш ip>
Нажимаем на клавиатуре с, а потом цифру 2

Я специально пишу, что нужно указывать наш IP адрес, чтобы не учитывать в статистике запросы самого резольвера, которых будет много. Далее в сочетании это магических кнопок с значит выдать детализацию по IP адресам, 2 — детализация до 2-го уровня доменов.

Так можно легко смотреть, кто и куда ходит, и какая атака идет сейчас.

Грабли (делюсь своими)

Их много. Как только вы поднимете резольвер, вы столкнетесь с криво настроенными роутерами или софтом. Можете получить тонны PTR запросов. Такое бывает достаточно часто, и вы это будете видеть, сможете исправлять, разбираться и делать вашу сеть лучше. Отдельный момент — это прекрасные китайские видеорегистраторы. К ним у меня особая любовь, как и у многих, наверное.

В вашей сети главная проблема в том, что вашим пользователям на ваши проблемы глубоко наплевать чаще всего. То есть то, что от пользователя идет паразитный трафик с DNS Water Torture его волнует мало, пока World of Tanks работают.

Сейчас говорили про простейшую вещь — про резольвер, теперь давайте усложним задачку.

Держим зоны

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

Как правило у себя держат зоны либо организации с особыми амбициями: «Мы крутые! Мы зоны лучше держим, чем какой-нибудь Dyn!», либо ЦОДы или провайдеры, от которых этого опять же этого ждут по умолчанию.

Не надо совмещать

Первая задача — не надо совмещать. Пожалуйста, не делайте этого никогда! Хотя мы найдем исключение из этого правила. Совмещать на одной машине резольвер и авторитетный сервер — это плохо . В чем проблема, я думаю, вы понимаете. Если клиент «увел» домен от вас (т. е. сменил ns-сервера у регистратора) или домен протух (т. е. истек его оплаченный период), Вы об этом вообще не узнаете никак. Потому, что вы можете не внести изменения локально.

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

Выбор софта

Главный момент: не надо думать, что вы здесь выбираете софт. Это ключевая ошибка в головах многих. DNS — это база данных, не пихайте ее в текстовый файл. Очень и очень плохо, если вы при помощи Ansible или chef генерируете текстовый файл, который потом засовываете в bind. Но я знаю — вы это делаете, а потом рассказываете о том, что оно плохо работает.

Поэтому ответ: PowerDNS

Вы знаете, что к bind есть патч, чтобы работать с MySQL, да? А вы его пробовали? Многие еще не знают про PowerDNS. Большая часть свято считает, что этот патч можно как-то использовать на старых версиях, но оно будет работать ужасно в плане производительности, потому что это просто набор костылей.

Опять привет убунтуводам

Если вы используете Ubuntu, то в стандартных репозиториях 16.04 лежит alpha-версия PowerDNS 4.х. Я не знаю, кому сказать спасибо за это. Она действительно работает, но с проблемками. Уже год, как я открыл к версии 4.х issue #3824. Я спрашиваю у разработчиков PowerDNS:

– Ребят, а ничего, что я MySQL перезапускаю, а у вас PowerDNS не подхватывает его обратно?
– Ух ты, прикольно!

Запомните этот баг, они уже 3 раза закрывали и 3 раза открывали в 4-й ветке. Поэтому — есть 3-я стабильная, у нее этих проблем нет, но на Debian / Ubuntu вам понадобится ее ставить из deb-файла. И на сегодня, на март 2018 года она уже небезопасна. Поэтому выход один — переходить на ppa от разработчиков для Вашей версии Ubuntu.

Вдумчивая архитектура

Здесь начинается сложная часть статьи — давайте подумаем про архитектуру. Как только мы пришли к PowerDNS, раз это база данных, мы хотим удобный редактор в вебе. А редакторов нет, кроме PowerAdmin. Это веб-приложение на PHP, и сразу понятно, что тому, кто его развернет вместе с DNS-сервером, надо руку отрубить — нельзя его на ту же машину ставить. В итоге возникает задача:

• Есть база данных.
• Есть сервер, который ходит в эту базу данных, чтобы получить ответы.
• Этих серверов несколько.
• Надо все синхронизировать.

Естественно, в первую очередь в голову приходит механизм трансфера зон *XFR, т. е. не важно IXFR или AXFR. Но если вы оставите этот механизм для передачи зон, вы себя запрете. Вы будете продолжать делать master/slave — и так и не уйдете от этих понятий.

Далее, у нас несколько DNS-серверов и необходимо доставлять на них базу данных. Получается, что есть машина с PowerAdmin, с актуальной базой данных, и нужно эту базу данных как-то раскатывать еще на кучу машин.

– Давайте возьмем, например, репликацию MySQL. Говорят, она прикольно работает!
– Она вам тоже не поможет. Репликация тут не лучший друг.

Поэтому схема выглядит так.

У вас есть сервер с PowerAdmin и MySQL. С DNS-сервера вы идете туда и делаете mysqldump с опцией skip-extended-insert (мы о ней скоро поговорим) и получаете SQL-файл.

Вы скажете: «Эка невидаль! Что мы, дампов никогда не делали?»

А дальше начинается интересное. Естественно, вы не можете, взяв dump в базе на допустим 700 доменов, загружать его в ту же базу. Поэтому его надо загрузить в соседнюю, а потом сделать RENAME TABLE. Вы спросите — зачем? Это 100% атомарно. RENAME TABLE — это офигительная штука, которая, как и переименование файла в Linux, либо отрабатывает, либо нет, у неё нет промежуточного состояния. Это очень удобно и удобнее, чем транзакция, потому что в разы быстрее. После того, как вы успешно этот dump загрузили, вы этот же файл кладете в git. Поскольку есть опция skip-extended-insert, то файлик получается git-friendly, т. е. у него на каждый insert одна строчка, и вы получаете вменяемый diff.

Главное здесь вот что: я хочу иметь возможность видеть diff от результатов «накатывания» базы.

Что получим

• Это очень простые операции: 225 строк на PHP во имя добра.
• Каждый DNS-сервер это делает каждые 2 минуты. Часы у них синхронизированы, поэтому у вас может быть любое количество серверов — они получат одинаковую базу данных.
• Опция skip-extended-insert позволяет делать не один большой монструозный INSERT, а много маленьких.

Несмотря на это, оно работает очень быстро и весь процесс засасывания нового дампа на 700 доменах занимает еле-еле 15 секунд. Да, время не растет пропорционально. То есть, если завтра у вас будет 1400 доменов, то это будет занимать 18 секунд, окей.

А про понятие master/slave забудьте, в данном контексте оно маловажно.

Хьюстон, у нас проблема

Все бы здорово и замечательно, но у нас есть одна проблема. Этот классный подход работает, только если мы для домена, в котором мы это делаем, и master, и slave. Если же это не так, начинаются сложности, которые мы сейчас будем побеждать.

Давайте переосознаем роль master/slave еще раз. Master шлет уведомления, как только у него изменилась зона, slave эти уведомления получает и что-то делает, при этом оба они отвечают на запросы.

Есть 2 стула варианта:

1. Клиент хочет, чтобы мы держали у себя slave. То есть у клиента где-то будет держать master, а мы должны забирать у него данные. Это как раз сложный вариант, который потребует телодвижений.
2. Клиент хочет, чтобы мы держали у себя master, а он будет slave, т. е. будет забирать у нас копию. Это простой вариант, мы просто разрешаем трансфер зоны клиенту.

Выход — назначить один из серверов (можно 2 — отдельный разговор) ответственным за прием *XFR. Это не может делать сервер с PowerAdmin, т. к. там нет DNS-сервера и некому принимать.

Схема выглядит так:

• Один из наших серверов получает *XFR.
• Вносит изменения в свою базу.
• Вкатывает эти изменения серверу, где стоит PowerAdmin.

У нас может быть 2 роли: просто DNS-сервер, который синхронизируется, а может быть DNS-сервер с ролью slave, который принимает *XFR, записывает себе в базу данных, и отдает изменения PowerAdmin, выполняя еще один скрипт.

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

Что мониторить?

Power DNS — это все-таки отдельный механизм, который надо мониторить. Ниже картинки из Zabbix. Мы снимаем Latency, т. е. сколько времени занял ответ в микросекундах, и хорошо видны всплески, если машина была занята или база данных тормозила.

Протокол, по которому пришел запрос тоже нужно мониторить. Там не всегда легитимен TCP, за ним тоже надо аккуратно наблюдать. Заодно можно понять, насколько популярен IPv6, здесь это 10% запросов.

Виды запросов тоже нужно снимать, тогда вы будете понимать, что происходит, и видеть, например, что запросы вида АААА, то есть адреса в IPv6 в нашей ситуации уже практически равны запросам IPv4.

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

Взболтать, но не смешивать

Увы иногда приходится использовать связку PowerDNS + unbound. К примеру, у вас есть локальный домен с хитрой структурой, которую неудобно настраивать в unbound. Кстати, так работает один из механизмов блокировки сайтов в России. Резольвер вашего провайдера может возвращать для «плохого» домена заглушку, для хорошего — нормальную запись. В корпоративной среде такое применяется, например, для блокировки социальных сетей или защиты от вирусов.

Архитектура

Архитектура здесь до боли проста — это просто смесь 2 компонентов, о которых мы только что говорили. То есть в свет смотрит PowerDNS, принимает запрос, смотрит в базу, к config-файле которой есть опция отправить запрос дальше вот этому серверу (стоящему на той же машине unbound), если чего-то нет в самой базе. Единственная особенность, что в рамках мониторинга мы на эту машину настраиваем template Zabbix 2 раза и картинок становится в 2 раза больше.

Контакты

» Код репозитория — https://github.com/maniaque/rootconf2017
» Почта — [email protected]
» Telegram — @maniaque_ruОтветы и вопросы — Хотелось бы услышать Ваш совет, каким образом можно фильтровать до сервера запросы определенных типов. Например, я хочу полностью отрезать IPv4 все запросы, чтобы они не доходили до сервера вообще.

— Эти опции есть и в PowerDNS, и в unbound. Еще есть вариант, используя IPtables, вы можете с помощью hex match выдергивать кусочек, смотреть, что там за запросы и просто их дропать полностью. Еще один вариант. Существуют различные DNS-прокси, причем даже авторы PowerDNS тоже выпускают свой резольвер, который поддерживает скрипты на Lua. Вы можете туда подсунуть свой скрипт, который будет делать любую кастомную магию. Есть для этого разные средства. Все зависит от того, что у вас за задача.

— Скажите, Вы у себя на сети внедрили блокировку запрещенных сайтов с помощью DNS? Статистика примерная есть?

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

— А по отчетам ревизоров заметны изменения после внедрения блокировки DNS?

Да. Для ревизора это отличный способ. Имейте это в виду.

— Вы своим клиентам, которые пользуются вашим DNS, даете IP адреса? Вы обеспечиваете доступность этих адресов, и каким образом?

Давайте коротенечко расскажу, как это работает. Вы же помните, что мы там вводим 2 адреса. Знаете, как смешно там работает failover. Смотрите, Windows и Linux ведут себя по-разному. Windows при недоступности первого переключается на второй и раз в 15 минут пытается по-прежнему тыркать первый и по возможности переключается на него. Linux этого не делает.

Во-первых, что надо понимать? Что failover средствами операционной системы не униформен и плох. Соответственно, ваша задача, чтобы оба IP, которые вы отдаете, как резольверы, светились всегда и работали. Поскольку мы это делаем с помощью маршрутизации, у каждого из наших серверов дополнительными IP к интерфейсу прописаны адреса его друганов. У нас их используется 3 и пока хватает.

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

— У Вас была табличка по передаче MySQL dump от серверов друг к другу. Вы говорили, что у вас получился не master/slave и master/master. То есть, грубо говоря, вы меняете всегда зону на одном из серверов и перекидываете на другой и split-brain не может получиться в этом случае?

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

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

— Нет, split-brain в том смысле, что вы на одном из серверов изменили запись, а на другом нет.

Смотрите, на самих DNS-серверах ничего не изменяется. Изменяется в одном месте, где PowerAdmin, а оттуда раскатывается на все остальные. Соответственно, такого не может быть, что мы забыли базу поменять где-то в другом месте. Мы как раз это и делали, чтобы так не было никогда.

Это была одна из наших проблем, когда был bind с текстовыми файлами. Было клево поменять зону в одном месте, потом забыть изменить серийник, а она XFR’ом на второй не перетекала. Это была наша боль, которую мы этим тоже устраняли.

— А еще есть какая-нибудь статистика по тому, когда перестать пользоваться XFR…

XFR — это механизм, который был придуман в условиях плохой связанности. Условно говоря, XFR, особенно инкрементальный XFR, придуман, чтобы полосу экономить. Но в современных реалиях полоса DNS сервера 5 Мб/с, больше он не ест. Поэтому, на мой взгляд, сейчас XFR — это механизм так себе. Поэтому я бы, в принципе, не рекомендовал смотреть в его сторону. Ребята из Power DNS в документации так и пишут, что если вы можете бэкенд как-то реплицировать без XFR и прочего, сделайте это. В нашем случае получилось здорово.

— Когда Вы рассказывали про ситуацию настройки авторитетного сервера, сказали, что якобы про репликацию Master/slave надо забыть, и мы отдаем на один сервер одинаковую конфигурацию со всего. В такой ситуации в SOA записи у нас есть какой-то ns сервер. А ns записей сколько получается? То есть, не будет ли такого, поскольку существуют разные чекеры DNS сервисов, правильно он настроен или нет, он будет ругаться типа: «У тебя 1 ns сервер, это очень плохо!» и т.д. Или мы сделаем одну ns запись несколькими IP’шниками?

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

— У меня легкие уточнения по поводу PowerDNS и изменения зоны. В 4-й версии есть PDNSutil edit. Он берет из базы зону, представляет ее в текстовом классическом виде. Говоришь save — он ее загружает обратно.

По поводу исправления issue — я месяц назад разговаривал с разработчиками PowerDNS — они очень мало притрагиваются сейчас к авторитетному серверу. У них все усилия брошены на DNS dist и recursor. Поэтому если хочется запатчить, лучше самому. В ближайший год они, похоже, ничего там делать не будут.

Меня 3-я версия устраивает. 4-ю я видел только потому, что она в 16.4 по дефолту приезжает. Это было из разряда «О, что есть!»

— Последнее. Как раз в сентябре будет меняться DNSSEC ключ на корнях, не забудьте обновить!

Спасибо.

— Вы говорили, что нельзя использовать форвардинг, нужно использовать рекурсивный резолвинг. У меня возник такой вопрос, а если все начнут использовать рекурсивные DNS — корневых серверов как бы мало?

Протокол DNS придуман так, что вы к корневым серверам будете ходить очень редко. Корневые сервера условно держат сейчас уже много Top Level Domain, но посмотрите TTL — там он огромный. Вы туда будете ходить очень редко — раз в месяц сходите, и после этого не будете.

— Вы имеете в виду, что наш резольвер отрезольвит ns из зоны.ru и будет уже ходить только к ним?

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

То есть злоумышленнику сейчас резольвер — лакомый кусок для атаки потому, что «отравлю ему кэш — отравлю кэш толпе!» Это плохо, неправильно и так не должно быть. Чтобы это решить, надо просто всунуть резольвер в коробку в ОС. Я не понимаю, почему до сих пор никто этого не делает. Это не настолько сложно.

— У Ubuntu, кажется, dnsmasq в коробке есть.

Нет, там плохо все, поверьте. dnsmasq вообще плохо. Но дело даже не в этом. Он есть только в FreeBSD, там есть unbound, он на local-хвосте висит и работает. Но процент пользователей FreeBSD — это отдельный разговор.

Умеете больше, выше, сильнее — программный комитет RootConf в составе РИТ++ ждет ваших заявок до 9 апреля. Также, как и рассказов о собственных граблях и шишках во всем спектре тем, касающихся поддержки и эксплуатации ИТ-проектов.

habr.com

Установка DNS сервера на Windows Server 2012 R2 Datacenter и создание зоны прямого просмотра | Info-Comp.ru

Сейчас мы установим роль сервера DNS-сервер на операционной системе Microsoft Windows Server 2012 R2 Datacenter, затем создадим зону прямого просмотра, а также вспомним, что такое вообще DNS и для чего он нужен.

И прежде чем устанавливать и настраивать DNS сервер, давайте вспомним, что такое DNS и DNS сервер. Так как подобной информации в Интернете полно мы рассмотрим это кратко и перейдем сразу к делу. Напомню, что в прошлых статьях мы рассматривали установку Windows Server 2012 R2 и установка и настройку DHCP сервера на этой же операционной системе, теперь продолжаем и на очереди у нас DNS сервер.

Что такое DNS и DNS сервер?

DNS (Domain Name System) – это система доменных имён, которая позволяет по доменному имени узнать IP адрес хоста и наоборот. Так как у каждого компьютера или сетевого устройства есть свой IP адрес и для того чтобы обратиться к тому или иному компьютеру или устройству соответственно нужно знать этот IP адрес, но так как запоминать определенную последовательность цифр не удобно, да и как если, например Вы обращаетесь ко многим компьютерам (запомнить просто не реально) поэтому чтобы  не запоминать эти цифры, и существует система доменных имен, например, что лучше для восприятия 192.168.1.1 или mycomp.  Вот такое простое определение, но так как материал для начинающих администраторов, этого вполне достаточно.

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

Хватит теории, и так как материал посвящен именно установки роли DNS сервер, давайте переходить непосредственно к этому.

Примечание! Как видно из названия, DNS сервер мы будем устанавливать на ОС Windows Server 2012 R2 Datacenter, только мы будем использовать, как и в прошлых статьях, ознакомительную версию.

Установка DNS сервера на Windows Server 2012 R2

Шаг 1

Открываем диспетчер серверов и выбираем «Добавить роли и компоненты»

Шаг 2

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

Шаг 3

На этом шаге, также ничего не нужно делать, все по умолчанию выбрано правильно именно так как нам и нужно, жмем «Далее»

Шаг 4

Затем предстоит выбрать сервер, на который будет производиться установка роли DNS сервера, так как у меня сервер один я его и выбираю, жму «Далее»

Шаг 5

Вот как раз на этом шаге и нужно выбрать, какие роли мы будем устанавливать, а мы соответственно будем устанавливать роль DNS сервер, поэтому выбираем его

Затем нам сразу предложат установить средства администрирования DNS сервера, и так как я буду администрировать его на этом же сервере, я жму «Добавить компоненты», чтобы на следующем шаге их не искать и принудительно не выбирать. А если Вы будете администрировать DNS сервер с другого сервера, то можете и не добавлять эти средства, а добавить их соответственно на том сервере, с которого будет осуществляться настройка и управление.

Затем жмем «Далее»

Шаг 6

И так как компоненты мы уже добавили нам искать их здесь не нужно, но для примера я покажу, где они находятся и что они уже выбраны, жмем «Далее»

Шаг 7

На следующем окне нам говорят, на что обратить внимание при установке роли DNS сервер, жмем «Далее»

Шаг 8

Все подтверждаем установку нажатием кнопку «Установить», ставить галочку «Автоматический перезапуск сервера» в данном случае не нужно.

Вот и все началась установка

Продлится она не долго минуты 3, и появится следующее сообщение, жмем «Закрыть»

Все, роль сервера DNS-сервер установлена. Для запуска средств управления DNS сервером используйте Диспетчер серверов->Средства ->DNS

Или через меню Пуск

Само средство управления выглядит следующим образом

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

На группе «Зоны прямого просмотра» щелкаем правой кнопкой мыши и выбираем «Создать новую зону»

После у нас запустится мастер создания новой зоны, жмем «Далее»

В следующем окне выбираем тип наше зоны, описание можете посмотреть непосредственно под каждым типов, я выбираю «Основную» жму «Далее»

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

Далее я выбираю «Создать новый файл», так как у меня другого DNS сервера нет, жму «Далее»

Затем предстоит выбрать «Тип динамического обновления» я пока такой функционал запрещу, но в последствии я всегда могу его включить, а Вы можете включить его, если, например, у Вас DNS сервер только для Вашей локальной сети, жму «Далее»

Заключительное окно, которое говорит нам, что все готово, мы соответственно и жмем «Готово»

Вот и все зона создана, давайте создадим запись типа A, например для нашего же сервера. Для этого по зоне щелкаем правой кнопкой мыши и жмем «Создать узел A или AAAA»

Затем вводим имя нашего узла, которое мы хотим, чтобы у него было, и соответственно какой у него IP адрес, это уже по факту. Жмем «Добавить узел»

Появится сообщение о том, что узел создан

И появится соответствующая запись

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

Как видите, система распознала по доменному имени его IP адрес. И на этом предлагаю заканчивать. Удачи!

info-comp.ru

Настройка обратного просмотра DNS в Windows Server 2008

Прямой просмотр нужен для разрешения доменных имен в ІР-адреса, обратный просмотр – для разрешения ІР-адресов в доменные имена.

В каждом сегменте сети должна быть зона обратного просмотра. В частности, если у вас есть подсети 192.168.10.0, 192.168.11.0 и 192.168.12.0, у вас должно быть три зоны обратного просмотра.

Стандартное имя зоны обратного просмотра составляется из идентификатора сети, выстроенного в обратном порядке, и суффикса in-addr.arpa. Зоны обратного просмотра из предыдущего примера будут называться 10.168.192. in-addr.arpa, 11.168.192.in-addr.arpa и 12.168.192.in-addr.arpa. Записи зон обратного и прямого просмотра должны быть синхронизированы. В случае сбоя синхронизации в домене может произойти сбой проверки подлинности.

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

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

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

3. Если вы настраиваете основной сервер, интегрированный с Active Directory, установите переключатель Основная зона (Primary Zone) и убедитесь, что установлен флажок Сохранять зону в Active Directory (Store The Zone In Active Directory). Если вы не хотите интегрировать DNS в Active Directory, установите переключатель Основная зона (Primary Zone) и сбросьте флажок Сохранять зону в Active Directory (Store The Zone In Active Directory). Щелкните Далее (Next).

4. Если вы настраиваете зону обратного просмотра для дополнительного сервера, установите переключатель Дополнительная зона (Secondary Zone) и щелкните Далее (Next).

5. Если вы интегрируете зону с Active Directory, выберите одну из следующих стратегий репликации:

• Для всех DNS-серверов в этом лесу (То All DNS Servers In This Forest) Это обширнейшая стратегия репликации. Помните, что лес Active Directory включает все деревья доменов, использующие данные каталога совместно с текущим доменом.

• Для всех DNS-серверов в этом домене (То All DNS Servers In This Domain) Выберите эту стратегию, чтобы реплицировать информацию DNS внутри текущего домена и его дочерних доменов.

• Для всех контроллеров домена в этом домене (То All Domain Controllers In This Domain) Выберите эту стратегию, если хотите реплицировать информацию DNS на все контроллеры домена внутри текущего домена и его дочерних доменов. Хотя эта стратегия обеспечивает более широкую репликацию информации DNS внутри домена, не каждый контроллер домена является DNS-сервером (вам и не нужно настраивать каждый контроллер домена как DNS-сервер).

6. Установите переключатель Зона обратного просмотра (Reverse Lookup Zone). Щелкните Далее (Next).

7. Укажите, для каких адресов вы хотите создать зону обратного просмотра (IPv4 или IPv6) и щелкните Далее (Next). Выполните одно из следующих действий:

• Если вы проводите настройку для IPv4, введите идентификатор сети для зоны обратного просмотра. Вводимые значения определяют стандартное имя зоны обратного просмотра. Щелкните Далее (Next).

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

8. Если вы настраиваете основной или дополнительный сервер, не интегрированный в Active Directory, задайте имя файла зоны. Стандартное имя файла для БД зоны DNS должно быть уже введено. Оставьте его неизменным или введите новое имя. Щелкните Далее (Next).

9. Укажите, следует ли разрешить динамические обновления. У вас есть три возможности:

• Разрешить только безопасные динамические обновления (Allow Only Secure Dynamic Updates) Если зона интегрирована в Active Directory, вы можете воспользоваться списками ACL, чтобы ограничить круг клиентов, которые могут выполнять динамические обновления. Если вы установите этот переключатель, динамически обновлять записи ресурсов смогут только клиенты с учетными записями компьютеров, прошедшими проверку, и одобренными ACL.

• Разрешить любые динамические обновления (Allow Both Nonsecure And Secure Dynamic Updates) Установите этот переключатель, чтобы позволить любому клиенту обновлять его записи ресурса в DNS при наличии изменений.

• Запретить динамические обновления (Do Not Allow Dynamic Updates) Этот переключатель отключает динамические обновления DNS. Его следует использовать только при отсутствии интеграции зоны с Active Directory.

10.Щелкните Далее (Next), затем щелкните Готово (Finish), чтобы завершить процесс. Новая зона добавляется на сервер, и автоматически создаются базовые DNS-записи.

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

logi.cc