2 dns сервера в домене настройка
- В зонах прямого просмотра DNS-сервера следует удалить зону "." (на жаргоне: "зона точка", "корень", "корневая зона", "зона корневых серверов"), если она там есть. После этого перезапустить службу "DNS-сервер".
- a) Если в вашем домене только один контроллер домена, то в "Свойствах TCP/IP" в разделе "Предпочитаемый DNS сервер" каждого интерфейса необходимо указывать только IP этого же самого интефейса, а в качестве "Альтернативный DNS сервер" не следует указывать вообще ничего.
b) Если в вашем домене два или более контроллеров домена, то на каждом контроллере домена, на котором работает DNS-сервер, в "Свойствах TCP/IP" каждого "внутреннего" (глядящего внутрь вашей локальной сети) интерфейса следует указать
- "первым сервером DNS" - IPшник любого другого (разумеется, ближайшего по топологии сети) контроллера этого домена с работающим DNS,
- "вторым сервером DNS" - IPшник этого же самого интерфейса, т.е. "самого себя" (но ни в коем случае не 127.0.0.1!). - Если на контроллере с работающим DNS установлено более одного сетевого интерфейса (внимание! это плохая практика! не стОит делать любой контроллер домена многодомным/multihomed по многим причинам!), то на всех "внутренних" интерфейсах надо прописать DNSы как указано выше, а на всех "внешних" (глядящих "наружу" вашей локальной сети, например, на провайдера) интерфейсах надо указать в качестве "первого DNS" только IP этого же самого интерфейса, т.е. "самого себя" (но ни в коем случае не 127.0.0.1!), а "вторым DNSом" не указывать ничего.
- В свойствах DNS-сервера на закладке "Пересылка" ("Forwarding") следует разрешить пересылку на DNS-сервер следующего (более высокого) уровня*. Изменения активизируются только после перезапуска службы "DNS-сервер".
* - тут необходимо пояснение с повторением:
- в "Пересылке" ("Forwarding") каждого DNS-сервера вашего домена следует указать один-два DNS-серверов вашего провайдера (больше не надо; объяснять сейчас "почему всего один-два" - значит запутать вас; просто примите на веру, а потом не спеша разбирайтесь с этим вопросом сами). [будет дополнено]
Подчеркиваем ещё раз [будет дополнено]: закладка "Пересылка" ("Forwarding") всех ваших DNS-серверов - единственное место во всех компьютерах вашего домена (серверах и рабочих станциях), где могут быть указаны айпишники DNS-серверов вашего провайдера. Нигде и никогда не вписывайте в "Свойства TCP/IP" айпишники вашего провайдера, даже на вашем шлюзе в Инет. Исключения могут быть, но если вам нужна эта статья как помощь в настройке, то запомните - нигде не вписывайте в "Свойства TCP/IP" айпишники вашего провайдера в пределах вашей локальной сети, кроме как в закладках "Пересылка" ("Forwarding") ваших DNS-серверов -- тогда у вас точно не будет ошибок.
Если же сделать наоборот (т.е. primary dns — он же сам, а secondary — второй сервер) , то загрузка сервера становится в разы дольше — окно "подготовка сетевых подключений при загрузке висит до 10 минут, в логах ошибки с невозможностью разрешать имена и прочих проблем из-за ошибок ДНС.
Правильно ли указывать в качестве primary dns адрес другого контроллера с другим днс-сервером? Увы, не нашел статьи в KB на эту тему, но на практике заметил, что только с такой настройкой сети сервер может нормально загружаться за приемлемое время и не сыпать ошибками. Да, dcdiag и netdiag отрабатывают тоже без ошибок в этом случае.
Все ответы
Я за перекрестное указание dns. Коллеги здесь выступали против. Мнения расходятся, у каждого способа есть плюсы и минусы.
Надо поглубже посмотреть физику процесса. В теории, если 127.0.0.1 недоступен, resolver должен сам переключиться на второй dns. Почему это не происходит на практике - не понятно.
Еще правильно будет сделать зависимость dns от netlogon, тогда загрузка вероятнее всего будет происходить корректно.
Еще тормозит загрузка из-за отсутствия сервера Global Catalog. А Global Catalog не рекоммендуется размещать вместе с Хозяином инфраструктуры. Что создает определенные проблемы когда dc всего лишь два.
В общем перезагрузка контроллера домена (особенно всех одновременно) это зачастую болезненное и затянутое по времени мероприятие.
Вот рекоммендации MS -
Рекомендации по настройке параметров клиента DNS в Windows 2000 Server и Windows Server 2003
В соответствии с ней допустимы оба варианта.
Сам практикую 1й DNS на себя, со 2го указываем остальные контроллеры домена.
Стартует не быстро (относительно, Exchange еще дольше стартует. ) но ошибок в журналах нет.
Спасибо за ссылку на статью в КБ — прочитал внимательно, задумался. В любом случае, оба способа имеют ме100. Если перекрестно указывать серверы, то увеличивается нагрузка на сеть (всерьез я бы это не рассматривал), плюс появляется возможность попасть на еще нереплицированную запись в зоне. Подумал, да и поставил первым себя, вторым второй контроллер. Посмотрю, как будет на практике. Кстати, загрузка все равно дольше (видимо, ждет старта службы ДНС. ), но незначительно.
Теперь по поводу адреса — почему не рекомендуют указывать 127.0.0.1, а именно адрес адаптера? Думаю, это на тот случай, когда установлены 2 и более сетевых адаптера (хотя такое ведь не рекомендуется для контроллеров), чтобы более точно указать тот интерфейс, который смотрит в локальную сеть, а ДНС-сервер заставить слушать только его же?
Все проще, при старте ваш ip регистрируется в dns a + ptr запись (посмотрите настройки tcp/ip).
Кроме, того DNS сервер может быть настроен так, что будет принимать запросы только с определенного ip.
По умолчанию DNS сервер обслуживает все адреса имеющиеся у компьютера, но можно уточнить какие именно обслуживать.
Спасибо за помощь. Резюмируя: все-таки разумнее указывать именно адрес конкретного интерфейса?
Да, вместо 127.0.0.1
Зоны, интегрированные с AD, и разделенная DNS могут породить конфликт, известный под названием «островная DNS» (island DNS). В случае с островной DNS два или несколько DC выполняют роль DNS-серверов домена, и на них, как обычно, размещается зона, интегрированная с AD. Но каждый DC располагает своей информацией. Каждый DC регистрирует идентификационную информацию о своем экземпляре зоны DNS, но никогда не реплицирует эту информацию на другие DC/DNS-серверы (то есть серверы, которые играют двойную роль DC и DNS-серверов). Поэтому каждый DC/DNS-сервер считает себя единственным на планете.
Островная DNS возникает только в корневом домене леса, только если используются зоны, интегрированные с AD, применяется разделенная DNS (каждый DNS-сервер настроен на разрешение запросов DNS лишь у себя) и только если в корневом домене имеется более одного DC/DNS-сервера. Насколько мне известно, возникновение островной DNS возможно в DNS-серверах на базе Windows 2003 и Windows 2000.
Чтобы избежать появления островной DNS, следует изменить конфигурацию DC/DNS-сервера. Во-первых, нужно назначить одну систему DC/DNS «ведущим» DNS-сервером зоны. Этот сервер не будет настоящим мастером. Регистрацию DNS по-прежнему станут выполнять несколько мастеров, но я пользуюсь этим термином для простоты изложения. Ведущий DNS-сервер должен по-прежнему указывать на себя (поле Preferred DNS server в окне TCP/IP Properties этой системы должно содержать только собственный IP-адрес данного сервера). Поле Alternate DNS server остается пустым. Затем нужно настроить другие DNS-серверы таким образом, чтобы они использовали IP-адрес мастера в качестве основного DNS-сервера, а какой-нибудь другой DNS-сервер — в качестве альтернативного. За исключением мастер-сервера, никогда не следует настраивать систему на обращение к самой себе как основной или альтернативной.
Предположим, у нас имеется три контроллера с именами DC1, DC2 и DC3. Все три DC являются DNS-серверами, расположены в корневом домене леса и хранят информацию о зоне DNS данного домена в интегрированной с AD зоне. Произвольно назначив DC1 ведущим, я настроил DC1 таким образом, чтобы в его поле Preferred DNS server содержался IP-адрес DC1, и оставил поле Alternate DNS server пустым. Я вставил IP-адрес DC1 в поле Preferred DNS server контроллера DC2, а в поле Alternate DNS server контроллера DC2 указал IP-адрес DC3. В поле Preferred DNS server контроллера DC3 я ввел IP-адрес DC1, а в поле Alternate DNS server контроллера DC3 — IP-адрес DC2.
Рассмотрим еще два DC (MYDC1 и MYDC2), связи между которыми организованы по тому же принципу. Если произвольно выбрать MYDC1 в качестве мастера, то в поле Preferred DNS server контроллера MYDC1 следует указать IP-адрес MYDC1 и оставить поле Alternate DNS server пустым. В контроллере MYDC2 требуется указать IP-адрес MYDC1 в поле Preferred DNS server. Но что делать с полем Alternate DNS server контроллера MYDC2? Это поле нужно оставить пустым.
Я против перекрестного указания ДНС, пришлось однажды разбираться с островной ДНС(вдобавок у меня контроллеры родительского домена "самоизолировались"). приятного мало было при приведении в рабочее состояние АД.
Дополнительные серверы обеспечивают отказоустойчивость 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. Мастер попытается проверить сервер. Если произошла ошибка, убедитесь, что сервер подключен к сети и вы ввели правильный ІР-адрес. Если вы хотите скопировать данные зоны ИЗ других серверов на случай недоступности первого сервера, повторите этот шаг.
Единственное неудобство в том, что вам приходится создавать и удалять каждую зону на обоих серверах, так как это автоматически не происходит. Вот почему вы создаёте доменную зону на master сервере и потом создаёте эту же доменную зону на slave сервере и указываете адрес master сервера. После того, как вы добавили ресурсные записи домена на master сервер, можете быть уверены, что slave сервер будет автоматически получать их от master сервера.
На протяжении многих лет интеграция Plesk и slave DNS сервера была непростой задачей. Подразумевается, что сервер Plesk должен быть master сервером. В Plesk есть режимы slave и master для доменной зоны и есть список ip адресов , которые отдаются доменной зоной . Но в плеск нет механизма создания новой доменной зоны на slave сервере. И этого механизма никогда не будет, потому что концепция плеск — это автоматизация хостинговых процедур на одном сервере. Для интеграции нескольких серверов разделённых для работы по видам сервисов, компания Parallels предлагает использовать продукты PPA (Parallels Plesk Automation) и PA (Parallels Automation).
На данный момент существует множество пользователей Plesk для которых решения PPA или РА превосходят их необходимые потребности для работы, так как им необходима только интеграция slave сервера. Ранее для решения этой проблемы каждый администратор Plesk должен был писать скрипты или приобретать коммерческие версии или вручную создавать и удалять доменные зоны на slave сервере.
Казалось бы, какие могут быть трудности. В Plesk есть собственный локальный сервер имён, который, предположим, будет master сервер. И есть система событий — давайте назначим исполнение нашего скрипта на события «создание DNS зоны» и «удаление DNS зоны» и проблема будет решена. Но, к сожалению, Plesk не поддерживает такие события.
КАК ЭТО РАБОТАЕТ
Plesk использует BIND как локальный сервер имён. Им можно управлять удалённо с помощью штатной утилиты rndc . Нет причин, по которым мы не можем установить BIND на удалённом сервере и управлять им с помощью rndc. В Plesk 12.5 реализован механизм “Custom DNS backend”, который может быть использован для подключения внешнего DNS сервиса, например AWS Route53.
Если вкратце, то этот способ позволяет зарегистрировать в Plesk скрипт, который будет получать описание DNS зоны в JSON формате с инструкциями для исполнения, такими как создание, изменение, удаление любой DNS зоны в Plesk. Это то, что нам нужно. Реализовывая этот функционал, Plesk подразумевали, что будет использоваться внешний DNS сервис вместо того, чтобы устанавливать BIND сервер в Plesk.
Также нет нужды удалять локальный сервер BIND . Этот скрипт может одновременно работать с локальной DNS службой. Такова идея использования данного расширения.
Это расширение работает по следующему алгоритму:
- Регистрируется slave сервер в своих настройках скрипта
- IP адрес slave сервер автоматически добавляется в список адресов разрешённых для трансфера доменных зон из сервера Plesk
- Когда вы создаёте, меняете или удаляете активную зону домена в Plesk , то эти действия происходят на локальном DNS сервере
- После этого скрипт запускается , получает доменное имя и выполняет соответствующую операцию
- Скрипт инициирует команду rndc для каждого подключённого slave сервера
- Slave серверы синхроинизируют доменные зоны с сервером Plesk.
Все настройки, такие как формат зоновых файлов, подключение и перезапуск служб управляются службой DNS. Администратор должен настроить slave сервер для работы с внешним сервером Plesk только один раз. После этого вы можете сообщить регистратору, что теперь Plesk сервер и slave сервер являются серверами имён для ваших доменов. Таким образом мы решили все вопросы обозначенные в начале статьи.
А ТЕПЕРЬ О ТЕХНИЧЕСКОЙ СТОРОНЕ - КАК РЕШИТЬ ЗАДАЧУ
Для установки slave сервера возьмём, к примеру, сервер с Centos 7
Установка BIND
В начале проверим что система имеет все последние обновления.
Если не указать "-y" ключ, то придется отвечать на все вопросы установщика, а с ним все ответы ставятся автоматически по умолчанию.
Установить bind и bind-utils
yum install bind bind-utils -y
Разрешим создание новых зон с помощью rndc. В файле /etc/named.conf, в фигурных скобках <>, напишите директиву:
Укажите ip адрес от которого должны быть приняты инструкции управления и установите BIND для прослушивания на всех доступных сетевых интерфейсах. Определите ключ rndc , который будет использоваться Plesk . В файле /etc/named.conf напишите:
Вот и всё, slave сервер установлен.
После этого установите расширение на сервере Plesk . В настройках расширения добавьте slave сервер, установите его ip адрес и ключ . Расширение создаст конфигурационный файл с настройками slave севрера для утилиты rndc.
Теперь Plesk будет автоматически передавать все созданные изменённые и удалённые зоны на slave сервер при выполнении следующей команды для каждого slave сервера:
Сейчас , когда вы добавили домен в Plesk, его ДНС зона автоматически создалась на slave сервер аналогично как на master сервере. Расширение (Slave DNS manager) доступно для загрузки здесь
Обращаем внимание, что Plesk не пр оводит техподдержку для для данного расширения . Это расширение лишь пример как можно решить техническую задачу.
Как видим, причин иметь свои NS-сервера достаточно. Обычно для решения этих задач хостеры настраивают пару серверов имен в режиме master-slave. При этом на обоих серверах создаются доменые зоны, но управление ресурсными записями доменных зон происходит только на мастере. А вторичный (slave) сервер имен загружает изменения автоматически с мастера. Таким образом, у вас всегда активны два сервера имен с идентичным набором доменных зон и с идентичным набором ресурсных записей.
Единственная неприятная мелочь — создавать/удалять зону нужно на обоих серверах. Автоматически этого не происходит. Поэтому создаем доменную зону на мастере. Затем создаем доменную зону на slave, указав адрес master-сервера. Все, теперь, добавляя доменные ресурсные записи на мастере, мы можем быть уверенными, что slave автоматически заберет их оттуда.
Как мы это реализовали?
Интеграция Parallels Plesk Panel и slave DNS много лет была не очень тривиальной задачей. Подразумевается, что Plesk-сервер выполняет роль мастера. В Plesk реализованы режимы slave/master для доменной зоны, существует глобальный список IP-адресов, которым можно делать запрос на получение доменных зон. Но механизма создания новых доменных зон на slave-сервере нет. И не будет. Потому, что концепция Plesk — это панель автоматизации хостинговых операций в рамках одного сервера. Если вам нужна интеграция нескольких серверов, разделение по типам сервисов – то у Parallels есть другие продукты: Parallels Plesk Automation, Parallels Operation Automation, и, в конце концов, большое комплексное решение Parallels Automation.
«Ну и в чем проблема?» — спросите вы. А дело в том, что существует ряд пользователей Plesk, которым перечисленные выше продукты не требуются, они overqualified для решения их конкретных задач. А нужна им только интеграция с slave-сервером имен.
Чтобы решить эту проблему, в свое время каждый администратор Plesk писал свои собственные программные решения. Или покупал коммерческие. Или вручную выполнял операцию создания/удаления доменных зон на slave-сервере.
Казалось бы, что сложного? У Plesk есть локальный NS-сервер, пусть будет мастером, есть система событий, давайте повесим выполнение нашего скрипта на события «создание DNS-зоны» и «удаление DNS зоны». Все будут счастливы. К сожалению, именно таких событий в Plesk нет.
Как это работает?
У Plesk в качестве локального NS-сервера используется BIND. У него есть возможность удаленного управления с помощью штатной утилиты rndc. Никто нам не мешает на удаленном сервере поставить BIND и управлять им через rndc. В Plesk 11.5 появился механизм «Custom DNS backend». Через него можно подключить сторонний DNS-сервис, например AWS Route53. Почитать об этом подробнее можно в документации.
В двух словах смысл этой функциональности можно описать как возможность зарегистрировать в Plesk скрипт, который будет получать JSON описание DNS-зоны, что нужно сделать с зоной, при каждом создании/обновлении/удалении любой активной зоны в Plesk. Это все, что нам нужно. При реализации этой функциональности подразумевалось, что вы не будете ставить локальный BIND с Plesk, а будете использовать внешний сервис. Но! Удалять локальный BIND совсем не обязательно. Скрипт может работать параллельно с локальным DNS-сервисом. Вот эту идею наше расширение и использует.
Читайте также: