Как зарезервировать роль DHCP на Server 2012 R2. Windows server 2018 r2 dns настройка

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

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

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

Открываем DNS оснастку на standalone сервере, в моем примере это сервер sccm.

Как настроить DNS сервер в windows server 2012R2-1 часть--01

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

Делее

Как настроить DNS сервер в windows server 2012R2-1 часть--03

Теперь на странице мастера мы видим возможные варианты зон

Как настроить DNS сервер в windows server 2012R2-1 часть--04

Основная зона

Если зона, хранящаяся на DNS-сервере, является основной, DNS-сервер становится основным источником сведений об этой зоне - он хранит главную копию данных зоны в локальном файле или в доменных службах Active Directory. Если зона хранится в файле, файл основной зоны называетсяимя_зоны.dns и размещается в папке сервера %windir%\System32\Dns.

Сначала создадим основную зону. Щелкаем далее.

Как настроить DNS сервер в windows server 2012R2-1 часть--05

Создать новый файл, если бы у вас был уже файл его можно было бы использовать.

Как настроить DNS сервер в windows server 2012R2-1 часть--06

Запрещаем динамические обновления в целях безопасности.

Как настроить DNS сервер в windows server 2012R2-1 часть--07

Готово

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

Видим наши записи

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

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

Создадим дополнительную зону.

Удаляем созданную до этого зону и выбираем создать новую

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

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

Выбираем дополнительная зона

Дополнительная зона

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

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

Пишем название зоны

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

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

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

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

Готово.

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

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

pyatilistnik.org

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

http://sys-team-admin.ru - установка и настройка DNS сервера в Windows Server 2008 R2. В доменной сети на Windows Server 2008 R2 нам понадобит...

1:41 - Что такое DNS 4:16 - Пространство имен, иерархия 9:30 - DNS запросы 18:10 - Зоны DNS 22:45 - Практика 28:30 - SOA, NS записи...

http://generaldesigners.blogspot.ru/ на блоге вы сможете найти полезную информацию по настройке Windows Server 2012 R2.

Разберемся с установкой DNS сервера.

http://sys-team-admin.ru - Настройка DHCP сервера в Windows Server 2008 R2. Для того, чтобы не указывать в ручную сетевые настройки...

Веб-каст демонстрирует возможности DNS Security Extensions (DNSSEC) в Windows Server 2012. В веб-касте вы найдете: - Установку роли...

20:50 Настройка сервера 40:30 Сеть Сайт: http://trainithard.ru/ Группа ВК: http://vk.com/trainithard Донат WMR R968467889622.

1:30 - DHCP, описание 7:50 - Получение IP через DHCP (DORA) 16:50 - Аренда (lease) IP, опции DHCP, резервации 27:03 - Демо: установка...

Первый (но не последний) видеоурок, посвященный Active Directory Domain Services. В нем я расскажу о том, что такое Active Directory,...

Установка серверной ОС Windows Server 2012 R2, развёртывание роли Active Directory Domain Services, развёртывание контроллера доме...

Установка роли DNS-сервера и добавление первичных доменных зон в Windows Server 2016 на виртуальной машине. Установка...

Windows server 2012 - Настройка обратной зоны DNS Установка, настройка DHCP Часть 2.

Пошаговая инструкция по настройке DHCP сервера на Windows Server 2012 R2.

http://onlineadmin.kuharbogdan.com - уроки по 1С бесплатно!

Установка и настройка AD, DNS, DHCP, CA ос Windows Server 2016 На виде обзор установки и настройки ос Windows Server 2016 на роли:...

Установка и настройка DHCP сервера на примере windows server 2016 Ничем не отличается от windows server 2012 и 2012 R2.

Лабораторная работа для студентов НТУУ "КПИ", ИПСА.

http://sys-team-admin.ru - Настройка домена Active Directory на Windows Server 2008 R2. Настроим сервер в качестве контроллера домена,...

Первоначальная настройка сервера Windows Server 2012 R2. Задание имени компьютера, настройка сети, статического...

Работа в VirtualBox (Windows Server 2000, Windows XP)

Данный видео курс рассказывает о системе DNS. В нем рассмотрены моменты: назначение DNS, типы DNS серверов, содер...

Перед вами небольшой видео урок на тему "Установка контроллера домена Windows 2012 R2 " с русским интерфейсом....

Настройка Windows Server 2012 для комфортной работы Ролик № 2 про установку и настройку ОС Мой основной сайт: http://www.k...

Windows Server 2016, часть 2/ Поднятие контроллера домена. Каналу нужна ваша поддержка. http://www.kunzite.ru/2016/11/donate.html За...

Отчет.

http://sys-team-admin.ru - Настройка интернет шлюза в Windows Server 2008 R2. Настало время подключить нашу доменную сеть к Интер...

Как установить и настроить DNS и Active Directory в Windows Server 2016.

Всем привет! В этом уроке будем рассматривать RRAS сервер, который в Windows выполняет роль маршрутизатора, NAT...

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

Поднятие роли обычного сервера Windows 2012 до контроллера домена в новом лесу. Ролик № 3 из серии роликов про...

In this (basic tutorial) video i will be showing how to setup your first DC and DNS server. Thank you for watching.

Данная видео инструкция поможет установить и настроить vpn подключение на сервере Windows Server Standart 2008 R2 Наш...

В данном веб-каст демонстрируется настройка DHCP сервера для раздачи IPv4-адресов на базе Windows Server 2008 R2.

Добавление роли Hyper-V, подключение СХД через iSCSI, настройка сети и NIC Teaming.

Проект домашний сервер: http://goo.gl/3CMKVE Настройка FTP сервера на Windows Server 2012R2 Группа Вконтакте http://vk.com/pclessons Мой...

minecraft okul zaman? 1 gta 5 online money hack pc anonymous external attack indir erotik film torrent growtopia mod simulator pb ng hilesi minecraft hayatta kalma serverleri nas?l ?sl?k cal?n?r ternebum dpfilelist generator v1.5

debojj.net

Как настроить DNS сервер в windows server 2008R2-1 часть

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

Открываем DNS оснастку на standalone сервере, в моем примере это сервер vcenter.

Как настроить DNS сервер в windows server 2008R2-01

Видим, что теперь можно настроить.

Как настроить DNS сервер в windows server 2008R2-02

Выбираем зону прямого просмотра, правый клик-свойства

Как настроить DNS сервер в windows server 2008R2-03

В мастере жмем далее

Как настроить DNS сервер в windows server 2008R2-04

Теперь на странице мастера мы видим возможные варианты зон

Как настроить DNS сервер в windows server 2008R2-05

Основная зона

Сначала создадим основную зону. Щелкаем далее.

Как настроить DNS сервер в windows server 2008R2-05

Пишем название зоны contoso.com

Как настроить DNS сервер в windows server 2008R2-06

Создать новый файл, если бы у вас был уже файл его можно было бы использовать.

Как настроить DNS сервер в windows server 2008R2-07

Запрещаем динамические обновления в целях безопасности.

Как настроить DNS сервер в windows server 2008R2-08

Готово

Как настроить DNS сервер в windows server 2008R2-09

Теперь проверим создался ли наш файлик. Идем c:\windows\system32\dns

Как настроить DNS сервер в windows server 2008R2-10

Файл contoso.dns.com можно открыть любым текстовым редактором.

Как настроить DNS сервер в windows server 2008R2-11

Видим наши записи

Как настроить DNS сервер в windows server 2008R2-12

Создадим дополнительную зону.

Удаляем созданную до этого зону и выбираем создать новую

Как настроить DNS сервер в windows server 2008R2-13

Как настроить DNS сервер в windows server 2008R2-03

Как настроить DNS сервер в windows server 2008R2-04

Выбираем дополнительная зона

Дополнительная зона

Как настроить DNS сервер в windows server 2008R2-14

Пишем название зоны

Как настроить DNS сервер в windows server 2008R2-15

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

Как настроить DNS сервер в windows server 2008R2-17

Как настроить DNS сервер в windows server 2008R2-18

Готово.

Как настроить DNS сервер в windows server 2008R2-19

pyatilistnik.org

Безопасность и тюнинг DNS в Windows Server 2012 R2 и 2016

Привет.

DNS – важная инфраструктурная служба. Настолько, что в предыдущей статье на тему безопасности DNS использовалась специальная иллюстрация:

В принципе, мало что изменилось – поэтому в данной, обновлённой версии статьи про безопасность DNS в Windows Server, я расскажу про то же самое, но уже детальнее. Будет рассматриваться Windows Server 2012 R2 и Windows Server 2016 – оба со всеми обновлениями на апрель 2016 года, для тюнинга будет использоваться ATcmd, в общем – работы много.

Безопасность и тюнинг DNS в Windows Server 2012 R2 и 2016

Механизм SocketPool – защищаемся от предсказуемости DNS-порта
Secure cache against pollution – защищаемся от отравления DNS-кэша
Блокируем раннее обновление кэша – Cache Locking
Привязка DNS-сервера к сетевым интерфейсам
Удалённое управление DNS-сервером
Настраиваем Global Query Block List
Отключение обработки рекурсивных запросов
Ограничение времени кэширования записей
Отключаем AXFR / IXFR трансфер у зон, интегрированных в Active Directory
Ограничение числа Resource Record’ов (RR) в ответе DNS-сервера
Настройка BIND secondaries
Настройка тайм-аута AXFR / IXFR трансфера
Настройка времени блокировки AXFR / IXFR трансфера
Фильтрация Name checking
Механизм Aging/Scavenging в DNS
Работа Round Robin и Netmask Ordering
Блокировка динамической регистрации по типу RR
Настройка EDNS0 в Windows Server 2012 R2
Настройка DNS-форвардеров в Windows Server
Ускоряем загрузку DNS-зон в Windows Server 2012 R2 и старше

Начнём.

Механизм SocketPool – защищаемся от предсказуемости DNS-порта

SocketPool появился как способ противодействия описанной в KB 953230 уязвимости, называемой иногда “Kaminsky bug”. Суть достаточно проста. В версиях Microsoft DNS до NT 6.1 для отправки данных DNS-сервера стартово инициализировался один сокет, от которого шло взаимодействие (в частности – ответы на UDP-запросы клиентов). Один сокет = разовая инициализация = одинаковый случайный ID транзакции. Это позволяло проводить атаку на перебор вариантов ID и с определённой вероятностью отравить кэш DNS-сервера путём отправки ему “заранее” неправильного ответа на предсказуемый запрос. А после, соответственно, DNS-сервер отдавал бы клиентам неправильную информацию из своего кэша, таким образом перенаправляя трафик туда, куда надо нарушителю.

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

Настройка SocketPool

По умолчанию пул равен 2.500 сокетам (притом, замечу, под пул выделяется одинаковое число и IPv4-портов, и IPv6 – т.е. в сумме по умолчанию зарезервированно 5 тысяч портов), но если ваш DNS-сервер обрабатывает запросы от внешних клиентов – увеличьте пул до 10К (если попробовать больше, выдаст DNS_ERROR_DWORD_VALUE_TOO_LARGE с кодом 9567). В случае, если DNS-сервер локальный – допустим, это DNS-сервер контроллера домена, и к нему обращаются клиенты из внутренней сети – стандартных 2.500 сокетов хватит.

Команда для задания количества сокетов, которые под себя “застолбит” сервис DNS:

Посмотреть текущую ситуацию с выделенными для SocketPool сокетам также можно в сводной информации по расширенным настройкам DNS server’а:

Как видно, параметр этот не одинок – продолжим про остальные.

Возможные проблемы, связанные с SocketPool, и настройка исключений

Возможные проблемы связаны с тем, что DNS Server застолбит под себя много UDP-сокетов, и различное ПО может от этого не иметь возможность сделать то же самое. Известный пример – это WDS (Windows Deployment Services). Эта служба резервирует для себя диапазон портов с 64.000 по 65.000, и в случае, когда DNS Server заберёт нужное число под SocketPool, могут возникнуть проблемы из-за наложения диапазонов DNS и WDS. Они решаемы, благодаря тому, что в WDS, который в Windows Server 2012 R2, встроен механизм динамического выбора портов. Включается он достаточно просто:

Замечу, что данный случай, когда существует штатный способ обойти ситуацию – единичная редкость. Вообще, так как механизм SocketPool резервирует под себя непрерывный блок UDP-портов, находящихся в верхней четверти всего доступного диапазона – т.е. с 49К и до 64К (это лишь 16К портов), то немудрено, что блок в 10К будет занимать много места и, возможно, конфликтовать с другими сервисами на том же хосте. Поэтому есть механизм, который позволяет исключить один или более диапазонов из SocketPool. Это делается специальной настройкой – штатного интерфейса у неё нет, поэтому выглядеть, например, исключение из пула портов диапазона 62000-63000, будет так:

Дополнительной и достаточно хитрой проблемой будет сценарий “Мы когда-то обновлялись с Windows Server 2003”. В этом случае в реестре может остаться технический параметр сетевого стека, актуальный до-NT-6.0 – т.н. MaxUserPort. Данный параметр ограничивает сверху диапазон выдаваемых приложению портов. То есть, если этот параметр есть, Windows Server 2012 R2 поменяет логику выдачи портов для DNS-сервера с “выдавать из диапазона 49K – 64K” на устаревший “выдавать с 1024 порта по MaxUserPort”. Поэтому для нормальной работы этот параметр надо, в случае его присутствия, удалить, он от устаревшей версии Windows Server и сейчас не нужен:

Суммаризируем советы по этому масштабному пункту:

Выставляем SocketPool везде в 2.500 – за исключением тех DNS-серверов, которые опубликованы в Интернет. У них – 10.000.
Заранее отключаем устаревшее управление диапазоном выделяемых портов, которое MaxUserPort. Оно нам сейчас только мешает и всё путает.
В случае острой необходимости используем исключения из диапазона SocketPool, чтобы не конфликтовать с другими сервисами, которые тоже хотят зарезервировать для себя ‘слушающие ‘UDP-порты.

Теперь двигаемся дальше.

Secure cache against pollution – защищаемся от отравления DNS-кэша

Идея этой настройки, появившейся ещё в Windows NT 4.0, и включенной по умолчанию с Windows Server 2003, проста. Она состоит в том, чтобы читать из ответа DNS-сервера только запрашиваемые ранее сведения, и игнорировать остальные. Рассмотрим пример. Допустим, на DNS-сервер пришёл запрос от клиента – “хочу A-запись с именем msdn.microsoft.com”. DNS-сервер посмотрел в зонах, расположеных на нём – не нашёл. Потом посмотрел у себя в кэше – тоже нет. ОК, на DNS-сервере включена рекурсия. Он запрашивает другой сервер (например, DNS провайдера или какой-нибудь публичный) и ждёт ответ. И сервер присылает ему ответ – вида “msdn.microsoft.com доступен по адресу 1.2.3.4”. Но иногда сервер хочет помочь – вдруг следующим запросом Вы захотите microsoft.com? И он присылает не только msdn.microsoft.com, но и ту информацию, которую он выяснил попутно – адрес microsoft.com. По умолчанию ответ обрабатывается и добавляется в кэш, т.к. предполагается, что сервер хороший, и присылает только полезную и нужную информацию. Но жизнь жестче. Поэтому надо включать параметр secure cache against pollution, чтобы исключить даже теоретическую возможность получения недостоверной информации из DNS-ответа. Проще всего сделать это через консоль управления сервером – открыть Properties, вкладку Advanced и установить нужное значение.

Блокируем раннее обновление кэша – Cache Locking

Механизм Cache Locking появился в Windows Server 2008 R2 и, по сути, является дополнительной мерой безопасности для защиты от “Kaminsky bug”. Работает Cache Locking просто – на какое-то время запрещает обновление успешно закэшированных записей. Параметр задаётся в процентах – допустим, если установить его в 50, то в случае, если Ваш сервер закэширует какую-нибудь запись, TTL которой равен 6 часам, все попытки обновить её на протяжении первых 3х часов будут игнорироваться. Установка параметра в 100, как понятно, приведёт к блокировке всех запросов на обновление имеющихся в кэше записей. Это – рекомендованное значение данного параметра, т.к. обычно Вы запрашиваете какую-то DNS-запись, сервер узнаёт про неё информацию и кэширует – перезапись “на лету”, пока не истекло время кэширования, не предполагается. Настраиваем данный параметр:

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

Привязка DNS-сервера к сетевым интерфейсам

По умолчанию DNS-сервер слушает трафик и реагирует на запросы со всех интерфейсов. Это включает в себя все IPv4-адреса и все IPv6 (как unicast’ы, так и link local’ы). Да и при добавлении нового интерфейса он будет сразу же использоваться службой DNS. Имеет смысл из соображений предсказуемости переключить эту настройку на явное указание адресов, на которых DNS-сервер будет принимать трафик. Например, если в инфраструктуре не используется IPv6, а DNS Server настроен “по умолчанию”, и на его интерфейсах включен сетевой компонент IPv6, он (DNS Server) будет обрабатывать запросы, пришедшие на адрес link local (вида fe80::идентификатор хоста), что является в указанной ситуации не нужным и не должно, согласно принципу Уильяма Оккама, существовать. Также не очевидно, что в случае установки нового сетевого соединения с хоста, на котором запущена служба DNS Server, подразумевается, что надо сразу же начать обрабатывать запросы клиентов, пришедшие на новопоявившийся интерфейс.

Как настраивается привязка DNS-сервера к сетевым интерфейсам

Необходимо зайти в настройки DNS Server, выбрать Properties и на вкладке Interfaces в явном виде выбрать только те адреса, на которые нужно принимать dns-запросы. Вот так:

Удалённое управление DNS-сервером

DNS-сервером можно управлять дистанционно через три технологически различных способа – это прямое подключение по TCP/IP (в данном случае, по сути, обычно и называемое RPC), отправка команд через Named Pipes и локальный вызов процедур (LPC). Имеются в виду, безусловно, способы подключения именно к службе и COM-объектам DNS-сервера, а не к хосту, на котором эта служба запущена. Так вот, если ваш DNS-сервер администрируется не всеми из них – а так обычно и бывает – то лишние надо выключать. Если это, допустим, опубликованный наружу DNS-сервер, который установлен на отдельной виртуальной машине, и управление осуществляется путём подключения администратора по RDP, то ничего, кроме LPC (чтобы MMC-консоль работала) серверу не нужно. Если это инфраструктурная виртуалка, к которой подключаются удалённой оснасткой, то ей надо только RPC поверх TCP/IP, никакие named pipes ей не нужны. Данная настройка (для случая с LPC) будет выглядеть так, иные варианты делаются по аналогии:

Настраиваем Global Query Block List

Глобальный блок-лист имён – достаточно интересная штука. Необходимость его использования вызвана тем, что в случае использования хостами динамической регистрации DNS-имён возможна ситуация, когда злонамеренный участник зарегистрирует well-known имя, которое используется сетевой службой (например, wpad или isatap). Имя другого компьютера или сервера ему зарегистрировать, в случае существования оных и включённого механизма secure updates, не дадут, а вот wpad допустим – пожалуйста, ведь сервера с таким именем нет, это служебный идентификатор. А после – данный компьютер будет отвечать на запросы пытающихся автоконфигурироваться клиентов вида “а дайте мне настройки” по адресу “http://wpad.имя_домена/wpad.dat”, отдавая им то, что посчитает нужным. Это неправильно. Ну и второй вариант злонамеренного использования – удалённый пользователь может получить информацию об инфраструктурных сервисах, запросив эти технические resource record’ы. Соответственно, GQBL нужен для того, чтобы отсечь эти возможности. Как этот механизм будет работать? Рассмотрим вариант для наличия в GQBL стандартного имени wpad. При добавлении имени в GQBL будут игнорироваться запросы для всех типов записей (это важно – не только A и AAAA, а всех) для всех зон, для которых данный сервер является authoritative. То есть, допустим, если на сервере есть зоны domain.local и _msdcs.domain.local, то запросы wpad._msdcs.domain.local и wpad.domain.local, несмотря на фактическое наличие/отсутствие данной записи, будут возвращать ответ, что запись не найдена. Замечу, что если что – это можно обойти, если создать зону с именем wpad.domain.local и в ней – пустую запись нужного типа. В именах зон проверка не происходит. Уязвимостью это не является, т.к. удалённо динамически зарегистрировать зону нельзя. Запросы для других зон (не находящихся на сервере) под это подпадать не будут (т.е. wpad.externaldomain.ru под этот механизм не подпадёт). Интересным является также момент про то, как данный механизм работает с логами. При первой блокировке в журнал пишется событие, где написано, что запрос от такого-то клиента заблокирован по причине нахождения искомого в GQBL. После запись уже не ведётся. Это не баг, а защита от простейшей атаки – переполнения журнала путём отправки огромного количества запросов на предсказуемо блокируемый FQDN. После перезапуска сервера счётчик сбросится на нуль и опять – первая блокировка будет записана в журнал, далее – нет. Теперь настройка.

Настройка Global Query Block List на Windows Server 2012 R2

Включить этот фильтр на уровне сервера просто:Задать содержимое – тоже несложно. Можно задать весь лист целиком, редактировать каждую запись отдельно – увы, только через реестр:

Отключение обработки рекурсивных запросов

Данная опция нужна только в одном сценарии – когда ваш DNS-сервер нужен исключительно для разрешения имён в тех зонах, которые на нём расположены, и не обслуживает произвольные запросы клиентов. Это, говоря проще, выделенная машина – например, для поддержки интернет-доменов предприятия, или в случае делегирования провайдером reverse lookup’ов (см. Создание обратной зоны с нестандартной маской). В упомянутых случаях DNS-сервер должен отвечать исключительно на один тип вопросов – про те зоны, которые ему явно известны и локально находятся. Абстрактные же запросы вида “а поищи-ка мне вот такое вот имя” не нужны и приводят к потенциальной DoS-атаке. Отключение рекурсии выглядит так:Как понятно из названия, вместе с ней отключаются и форвардеры – это логично, т.к. серверу без рекурсии форвардеры не нужны – он принципиально не обрабатывает запросы, для которых может понадобиться запрос какого-либо другого сервера.

Ограничение времени кэширования записей

Записи, которые DNS-сервер получил от других DNS-серверов, не только передаются запрашивающим клиентам, но и кэшируются на сервере. Время кэширования указано в самой записи – у неё есть личный TTL. В ряде случаев имеет смысл сделать работу более динамичной и ускорить актуализацию записей, установив максимальный TTL для всех RR’ов на сервере. Простой пример – некто установил огромный TTL (например, 42 дня), а по факту запись иногда меняется. В этом случае пока запись не устареет в кэше, ваш DNS-сервер будет давать неверный/устаревший ответ. Проще указать некую верхнюю границу – допустим, сутки – и записи с любыми TTL не будут храниться в кэше дольше этого срока, и сервер будет их запрашивать. Ничтожный рост трафика (один доп.пакет в день) гораздо лучше, чем, допустим, три недели испытывать проблемы с электронной почтой, потому что кто-то обновил MX, но забыл, что TTL выставлен огромный, поэтому изменение по факту применится очень нескоро. Этому, кстати, способствует тот момент, что в интерфейсе Microsoft DNS Server изменение TTL у DNS-записи доступно только в расширенном режиме работы. Вот как окно редактирования DNS-записи выглядит обычно:А вот как в случае, когда в меню View включён пункт Advanced:Не забывайте про то, что нужно выставлять разумные TTL у записей. Ну а теперь как ограничить максимальный срок жизни записи в кэше DNS-сервера: 86400 – это секунд в сутках, как понятно. Не менее важным параметром является ограничение времени кэширования негативного ответа. Суть достаточно проста – в случае, если в качестве ответа на запрос пришёл отказ, ваш DNS-сервер запоминает это, чтобы при повторных запросах каждый раз не повторять обращение – ну, экономит силы. Нет смысла раз в секунду по-честному бегать и проверять, не появилась ли запись, если удалённый сервер сообщил, что её нет. Однако на практике данный параметр желательно настроить на какой-то небольшой интервал времени – чтобы с одной стороны, часто запрашивающий клиент не мог перегрузить DNS-сервер, а с другой, при появлении запрашиваемой записи на удалённом сервере мы бы могли про это узнать в разумное время. Я поставлю время кэширования негативного ответа в 5 минут:

Отключаем AXFR/IXFR трансфер у зон, интегрированных в Active Directory

В том случае, если все сервера, на которых находится определённая зона, расположены на контроллерах Active Directory, то наличие возможности трансфера зоны стандартным способом – AXFR / IXFR запросом по TCP 53 является уязвимостью, так как может помочь потенциальному злоумышленнику узнать дополнительные сведения об инфраструктуре. Притом достаточно простым способом – например, подключившись при помощи nslookup и выполнив команду ls. Нормальная же репликация зоны происходит через механизмы LDAP-репликации Active Directory. Отключаем просто – открываем свойства (Properties) у нужной DNS-зоны, выбираем вкладку Zone Transfers:Это надо сделать не только у зон, интегрированных в Active Directory, но и у всех копий зоны, находящихся на secondary-серверах, с которых не забирают копию другие secondary-сервера.

Ограничение числа Resource Record’ов (RR) в ответе DNS-сервера

Данная настройка позволит обойти одну редкую, но неприятную проблему, связанную с разным поведением DNS-клиентов. Суть проста – в случае, когда в ответ надо добавить много записей, и, несмотря на EDNS0 и прочие ухищрения, они не влезают, у ответа ставится бит “неполный” – т.н. “truncation bit”. По идее, после получения ответа с таким битом, запрашивающий должен насторожиться и переспросить повторно, но уже по TCP (не забывайте, DNS-сервер умеет отвечать на запросы не только по UDP), чтобы получить не-урезанный ответ. Однако так поступают не все клиенты. Более того, высока вероятность того, что где-то в цепочке передачи рекурсивного запроса кто-то один не будет поддерживать запросы/ответы по TCP, поэтому информация просто потеряется – грубо говоря, клиент, получив не полный ответ, а урезанный, запросит иным способом, а в ответ – тишина, в результате клиент может решить, что имя просто не разрешилось полноценно. Чтобы минимизировать вероятность этой ситуации, нужно сделать ряд шагов. Первым делом – разберитесь с максимальным размером UDP-ответа. Чем лучше разберётесь – тем ниже вероятность возникновения упомянутой ситуации. Вторым – проверьте, все ли ваши DNS-сервера отвечают по TCP. Для этого в ATcmd есть встроенный тест – команда test dns ports, которой надо лишь указать имя домена (например, локального домена Active Directory) – она найдёт все NS-сервера за этот домен, и попробует запросить у каждого и UDP- и TCP-вариант ответа. Обеспечение возможности клиентов посылать вашим DNS-серверам запросы через TCP – это тот минимум, который вы можете сделать, т.к. не можете влиять на все DNS-сервера в рекурсивной цепочке. Примитивный подход “DNS работает только через UDP, через TCP только трансфер зон, поэтому TCP за исключением трансфера надо блочить на firewall’е” не работает – вы решите массу проблем и уберёте непонятные сбои, если клиенты смогут нормально переспрашивать DNS-сервер по TCP. А теперь можно и ограничить число RR в DNS-ответе. Я поставлю 28 (это максимальное ограничение).

www.atraining.ru

Как зарезервировать роль DHCP на Server 2012 R2

Цель: И тут думая о резервировании я подумал, почему же делают два домен контроллера, да понятно что выдача билета аутентификации проходила без каких либо проблем с одним домен контроллером, но это понятно. С ролью DNS все тоже понятно, а как быть с ролью DHCP (вариант где сервис DHCP на сетевом оборудовании, к примеру Mikrotik я не рассматриваю). Открыв книги по Windows администрированию меня заинтриговала тема настройка отказоустойчивого DHCP средствами самой Windows. Вот этому я и посвятил данную реальную заметку.

Исходные данные:

srv-dc1 (домен контроллер с ролями AD,DNS,DHCP)

OC: Server 2012 R2 Standard

IP: 10.90.90.2/24

srv-dc2 (домен контроллер с ролями AD,DNS)

OC: Server 2012 R2 Standard

IP: 10.90.90.3/24

srv-gw (шлюз на базе Mikrotik)

Сперва все задачу прорабатываю на тестовом окружении под Virtualbox своей домашней/рабочей системы Ubuntu 18.04 Desktop amd64 ноутбука Lenovo E555

Шаг №1: После того, как на втором домен контроллере srv-dc2 подняты роли AD,DNS следует проверить, что ошибок нет, для этого есть утилита командной строки dcdiag и также проверяем состояние репликации:

C:\Windows\system32>repadmin /syncall

CALLBACK MESSAGE: The following replication is in progress:

From: 8b2ce901-20be-462c-9989-14e9a0ece499._msdcs.polygon.local

To : fd07c239-b3de-4468-b747-28310c873ed2._msdcs.polygon.local

CALLBACK MESSAGE: The following replication completed successfully:

From: 8b2ce901-20be-462c-9989-14e9a0ece499._msdcs.polygon.local

To : fd07c239-b3de-4468-b747-28310c873ed2._msdcs.polygon.local

CALLBACK MESSAGE: SyncAll Finished.

SyncAll terminated with no errors.

Шаг №2: Поднимаем роль DHCP на втором домен контроллере srv-dc2. Заострять внимание на этом шаге нет необходимости все как обычно. Важно: не нужно настраивать область обслуживания сети, данная настройка должна будет в автоматическом режиме добавиться после настройки отказоустойчивости.

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

Шаг №3: Нужно определиться, как будет работать DHCP—сервис: это либо разделение областей (Split Score), т. е. Один сервер с ролью DHCP использует, к примеру 50% из пула адресов, а оставшиеся 50% другой сервер. Есть еще другой способ работы — это Failover (позиционирует как Отказоустойчивый). Т.е. если один сервер с ролью DHCP отказывает, вместо него работает другой. Мне кажется в этом и суть двух и более домен контроллеров. В этом режиме работы мне интересен вариант Failover + Host Standby Mode (Режим горячей замены) — один сервер будет действующим и если что-то с ним случает пассивный (второй сервер) становится основным.

Шаг №4: Несколько серверов с ролью DHCP в одной оснастке

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

на srv-dc1: Win + R → control.exe → Administrative Tools — и через правый клик мышью по DHCP → Add Server → This Server: Browse → Enter the object name to select: ввожу srv-dc2 и нажимаю Check Names после чего хост проверяется на соответствие и подчеркивается, нажимаю OK, OK

Шаг №5: Создаю отказоустойчивый DHCP сервис

Переключаюсь на srv-dc1: Win + R → control.exe — Administrative Tools — DHCP и по имеющейся области обслуживания сети: DHCP → srv-dc1.polygon.local — IPv4 — Scope [10.90.90.0] lan через правый клик мышью выбираю Configure Failover. Теперь двигаюсь согласно шагам запущенного мастера:

Available scopes: отмечаю галочкой Select all

у меня одна область это 10.90.90.0

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

Parther Server: → Add Server → This server: Browse → ввожу srv-dc2 и нажимаю Check Names → OK (окна Select Computer) → OK (окна Add Server) — Next (окна Configure Failover) — привожу настройки к следующему виду ниже представленного скриншота:

Теперь нужно пояснить обозначение параметров:

Relationship Name (Название конфигурации)— задается уникальное название создаваемой конфигурации.
Maximum Client Lead Time (Максимальное время упреждения клиента)— максимальное время аренды IP-адреса выдаваемого доступным сервером.
Mode (Режим работы):
Hot Standby (горячей замены) —выбираем состояние работы дополнительного сервера: Активный / Резервный и задаем количество IP-адресов в процентом отношении, для резервирования дополнительного сервера.
Addressess reserved for standby server: (Процент зарезервированных адресов) ставлю 100%, т. е. в режиме горячего резервирования указывается процент диапазона адресов в области для резервного сервера. Количество адресов, соответствующее указанному проценту будет закреплено за резервным сервером.
State Switchover Interval: ( Интервал автоматического переключения. ) 10 minutes → Сервер, который теряет канал связи с партнёром переходит в режим прерванной связи. Потеря связи может быть связана с проблемами в сети или с выключением сервера-партнёра.
Enable Message Authentication (Включение проверки подлинности сообщений) — Для настройки проверки подлинности сообщений между серверами.
Shared Secret (пароль) — Задается пароль для аутентификации серверов между собой. Я ставлю себе Aa1234567@!

И после нажимаю Next — Finish, если все успешно, то результирующая должна иметь статус Successful, если так то нажимаем Close

Шаг №6: Если проверить, а появились ли настройки на втором srv-dc2.polygon.local, то да в той же самой оснастке DHCP развернув srv-dc2.polygon.local — IPv4 — вижу область Scope [10.90.90.0] lan, открыв ее свойства и перейдя на вкладку Failover что данный сервис (DHCP) является второстепенным от главного srv-dc1.polygon.local, его режим «Hot standby», роль (Role of this Server): Standby и т. д. Повторив все тоже самое на srv-dc1.polygon.local видно что его роль (Role of this Server): Active.

На заметку: В настройках области Scope Options должны быть обязательно прописаны записи 006 DNS Server оба сервера с ролью DNS.

Итого: По умолчанию при создании области DHCP я воспользовался дефолтной настройкой жизни выданного адреса от DHCP сервера равной 8 дней, если srv-dc1 будет недоступен то его функциональные обязанности возьмет на себя srv-dc2 и статус роли сменится.

Шаг №7: Можно проверить на примере как это работает. На srv-dc1.polygon.local → DHCP — Scope [10.90.90.0] lan — через правый клик мышью выбираю Deconfigure Failover — OK — Close, после создаю отказоустойчивое соединение, но следует в этапе указания партнера не забыть снять галочку с пункта «Reuse existing failover relationships configured with this server (if any exist)» (если этого не сделать подхватятся ранее имевшие место быть настройки), как сделано выше по заметке. Отключаю сеть на srv-dc1 и через пару минут проверив статус srv-dc2 вижу что у него сменилась:

Mode: Hot standby
Max Client to Lead Time: 1 hrs 0 mins
State Switchover Interval: 1 mins
State of this Server: Lost contact with parther
State of Parther Server: Not available
Role of this Server: Standby
Addressess Reserved for Standby: 100%

Теперь проверяю, как поведет себя рабочая станция (в рамках этой заметки пусть это будет W7X64):

C:\Windows\system32>ipconfig /release → удаляю сетевой адрес

C:\Windows\system32>ipconfig /renew → запрашиваю новый

C:\Windows\system32>ipconfig /all | findstr /C:"DHCP"

DHCP включен. . . . . . . . . . . : Да

DHCP-сервер. . . . . . . . . . . : 10.90.90.3 → режим отказоустойчивости успешно отработал, сейчас выдачей адресов занимается srv-dc2.polygon.local, если включить сеть на srv-dc1.polygon.local и проделать на рабочей станции все с нуля, то, сетевой адрес она получит уже с srv-dc1.polygon.local

C:\Windows\system32>ipconfig /all | findstr /C:"DHCP"

DHCP включен. . . . . . . . . . . : Да

DHCP-сервер. . . . . . . . . . . : 10.90.90.2

Получилось разобрать, мне нравится такой вид отказоустойчивости. Интересующая меня тем разобрана, на этом я прощаюсь, до новых встреч, с уважением автор блога Олло Александр aka ekzorchik.

www.ekzorchik.ru

Установка и настройка DNS на Windows Server 2012 R2 » Самоучка

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

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

Откройте консоль "Диспетчер серверов", переключитесь на "Локальный сервер" и в меню "Управление" жмем "Добавить роли и компоненты":

Откроется мастер добавления ролей и компонентов, жмем "Далее":

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

Выбираем сервер и жмем "Далее":

На вкладке "Роли сервера" выбираем: "DNS сервер", нам предлогают добавить необходимые компоненты, выбираем: "Добавить компоненты", жмем "Далее":

На вкладке "Компоненты" жмем "Далее":

"Далее":

"Установить":

"Закрыть":

На этом установка завершена.

Настройка DNS на Windows Server 2012 R2 на конкретных примерах.

Одной из первых задач, которая должна выполняться сразу же после установки DNS-сервера, является настройка его TCP/IP-параметров таким образом, чтобы при преобразовании имен DNS он указывал на самого себя, если только не имеется никакой особой причины, чтобы он этого не делал.

Открываем "Диспечер серверов", "Локальный сервер" и жмем на доступное интернет соединение:

В открывшемся окне выбираем "свойства":

Дважды щелкните на элементе Протокол Интернета версии 4 (TCP/IP):

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

В этом же окне жмем "Дополнительно", и в окне "Дополнительные параметры", жмем "Добавить IP адрес"

Вписываем дополнительный IP адрес и маску (дополнительнгый IP адрес должен находиться в диапазоне подсети основного IP адреса), затем жмем "Добавить" и "OK":

В Диспетчере серверов в меню "Средства" выбираем "DNS", откроется "Диспетчер DNS":

В меню действие выбираем "Настроить DNS сервер":

Откроется мастер настройки DNS сервера, жмем "Далее":

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

Оставляем по умолчанию и "Далее":

Выбираем "Основная зона" и "Далее":

Задаем имя зоны. Так как у нас уже есть один сайт (admin), созданный в прошлой статье ( Установка и настройка веб-сервера IIS + PHP + MySQL на Windows Server 2012 R2 ), создадим для него зону "admin. malwselennaia.ru" (У Вас должно быть свое доменное имя) и жмем "Далее":

Выбираем "Создать новый файл" и жмем "Далее":

Оставляем по умолчанию и жмем "Далее":

"Да создать зону обратного просмотра" и "Далее":

Выбираем тип зоны и "Далее":

Оставляем IPv4 и жмем "Далее":

Вводим идентификатор сети (У Вас может быть по другому) и "Далее":

Выбираем "создать новый фаил" и "Далее":

Оставляем по умолчанию и "Далее":

Выбираем : нет не пересылать запросы ижмем "Далее":

Проверяем и жмем "Готово":

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

Дважды щелкните на элементе "сервер имен":

Откроется окно свойств созданной нами зоны. Выделяем имя нашего сервера и нажимаем "изменить".

Откроется окно редактирования записей. Выделяем имя нашего сервера и нажимаем "Разрешить в адрес".

Жмем "OK", "применить" и "OK"

Щелкаем мышкой в окне зоны, в открывшемся меню выбираем "создать узел А"

В открывшемся окне вводим созданный ранее дополнительный IP адрес (У Вас может быть другим) и нажимаем "Добавить узел"

Жмем "Ok" и закрываем окно "Новый узел"

Возвращаемся в Диспетчер серверов и в меню "средства" выбираем "Диспетчер служб IIS":

В диспетчере служб IIS выделяем созданный нами сайт admin и в правой колонке "Действия" жмем "Привязки..."

В открывшемся окне жмем "Изменить":

Здесь изменяем IP адрес и имя узла. Жмем "Ok":

"Закрыть":

Возвращаемся в диспетчер IIS и в колонке "Действия" выбираем "Обзор admin.malwselennaia.ru":

И, если все прошло успешно, видим страничку входа:

Добавление нескольких сайтов на Windows Server 2012 R2.

Далее добавим на наш сервер еще один веб-сайт. Для примера возмем CMS DLE (DataLife Engine), скачать можно здесь: http://dle-news.ru/demo.html

Установка DLE.

Сначала необходимо создать директорию для нашего сайта. Создаем папку, предположим, в уже созданной при установке IIS директории C:\inetpub\wwwroot\, и назовем (для удобства) "dle10.1":

И копируем туда распакованный дистрибутив DLE:

Далее заходим в phpMyAdmin:

Вводим установленный нами пароль и попадаем на главную страницу phpMyAdmin :

Нажимаем на вкладку "пользователи" и попадаем на страницу "Обзор учетных записей"

Нажимаем "Добавить пользователя", и в открывшемся окне вводим данные пользователя:Имя пользователя: предположим dle10.1Хост: localhostПароль: например dle10.1Подтверждение: dle10.1

Чуть ниже ставим точку на "Создать базу данных с именем пользователя в названии и предоставить на нее полные привелегии". Жмем OK:

Далее заходим в "Диспечер IIS",правой кнопкой мыши кликаем "сайты", и в открывшемся меню нажимаем "Добавить веб-сайт..."

Откроеться диалоговое окно "Добавление веб сайта".

Указываем :Имя сайта - допустим: dle10.1Физический путь - указываем где расположенна директория веб сайта: у нас C:\inetpub\wwwroot\dle10.1Имя узла - указываем название сайта(которое будем вводить в браузере): в нашем случае dle10.1.malwselennaia.ru и потом жмем Ok

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

Откроется мастер создания новой зоны. Жмем "Далее":

Выбираем "Основная зона". Жмем "Далее":

Вводим имя зоны (в моем случае dle10.1.malwselennaia.ru) и "Далее":

Оставляем по умолчанию. "Далее":

Тоже по умолчанию и "Далее":

Все проверяем и "Готово":

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

Дважды щелкните на элементе "сервер имен":

Откроется окно свойств созданной нами зоны. Выделяем имя нашего сервера и нажимаем "изменить".

Откроется окно редактирования записей. Выделяем имя нашего сервера и нажимаем "Разрешить в адрес".

Жмем "OK", "применить" и "OK"

Щелкаем мышкой в окне зоны, в открывшемся меню выбираем "создать узел А"

Возвращаемся в диспечер IIS. Выделяем наш сайт и правой кнопкой мыши открываем меню, выбираем "Редактировать разрешения":

Откроется окно свойств, переходим на вкладку "Безопастность"

Нажимаем "Изменить":

Откроется окно разрешений для группы dle10.1, жмем "Добавить":

Жмем "Дополнительно":

Жмем "Поиск":

Выбираем "IUSR". Жмем OK:

Выставляем разрешения и нажимаем применить и OK:

Далее можно переходить к установке.

Вводим в браузере: dle10.1.malwselennaia.ru (это исключительно в моем случае, у Вас адрес другой) и жмем начать установку:

Далее принимаем лицензионное соглашение и жмем продолжить:

"Продолжить":

Вводим данные и жмем продолжить:

Ну вот готово:

Ну правда не совсем готово.

Попытаемся открыть любую новость и получаем ошибку:

Возвращаемся в диспетчер IIS. Выделяем наш сайт, открываем модуль переопределения адресов:

В колонке действия жмем "Импортировать правила":

Копируем содержимое файла : ".htaccess"(лежит в корне сайта) и вставляем в поле "Правила переопределения", нажимаем "применить"

Теперь проверим результат:

На этом все.

malwselennaiaru.ru

DNS в Windows Server 2008 R2 | Windows IT Pro/RE

Служба DNS, обеспечивающая преобразование доменных имен в IP-адреса, — не просто система распознавания имен для всего Интернета. Это критически важный компонент Active Directory (AD), необходимый для обнаружения сетевых ресурсов. Но несмотря на повсеместный переход с системы WINS на DNS в сетях Windows в последнее десятилетие, начинающим администраторам все так же трудно разобраться в сложной иерархической организации DNS.

Интеграция Active Directory и DNS

Чтобы понять, как DNS сочетается с AD, подготовим типовую структуру AD для средних и крупных компаний. Построим один лес с двумя доменами (рисунок 1). Первый домен часто именуется пустым корневым (empty root) или просто корневым доменом. Пустой корневой домен находится на верхнем уровне иерархии AD и, как видно из имени, не содержит никаких ресурсов. Благодаря доменам такого типа компании получают более гибкие и лучше разделенные роли безопасности, нежели в единственном лесе/единственном домене. Второй домен расположен ниже пустого корневого и потому является дочерним; он функционирует как основной домен компании, в котором расположены ресурсы (например, группы, учетные записи пользователей и компьютеров).

Рисунок 1. Один лес с двумя доменами

Начнем с запуска утилиты Dcpromo на первом сервере, чтобы создать лес и пустой корневой домен. Зарегистрируйтесь на сервере Server 2008 R2 в качестве администратора. Убедитесь, что серверу назначено подходящее имя, такое как DC1, и задайте IP-адрес, маску подсети и шлюз по умолчанию на сетевом адаптере сервера. Настройки DNS для сетевого адаптера можно оставить пустыми и предоставить Windows ввести локальный адрес.

Запустите утилиту Dcpromo из меню Start и создайте новый лес и домен с именем ADcompany.com. Обратите внимание, что я использовал AD как приставку к имени компании, чтобы разделить внутренние и внешние пространства имен DNS. ADCOMPANY будет именем NETBIOS для домена. Хотя домен предназначен только для внутреннего использования, важно зарегистрировать домен ADcompany.com в Интернете, чтобы исключить случайное перенаправление клиентов на устройство вне зоны контроля компании. Также принято использовать иерархию пространства имен AD.company.com, где AD становится именем NETBIOS для домена. В этом случае, если имя company.com уже зарегистрировано компанией в Интернете, не требуется никаких дополнительных действий.

На экране Additional Domain Controller Options должен быть установлен флажок DNS server. Нажмите кнопку Next, и Dcpromo начнет проверять назначенные параметры. Система выдаст предупреждение о невозможности создать делегирование, так как не найдена полномочная родительская зона. Другими словами, Dcpromo не может найти полномочный сервер DNS (то есть сервер, содержащий основной или вторичный экземпляр данных зоны для домена. com), где можно создать зону делегирования для домена ADcompany.com.

В зоне DNS содержатся все записи ресурсов для одной части пространства имен, такой как ADCOMPANY или COM. Это внутренний корневой домен AD, поэтому запись делегирования в общедоступной зоне COM необязательна, и предупреждение можно игнорировать. Значение делегирования прояснится после создания дочернего домена.

Тестирование с использованием Dcdiag

После завершения работы Dcpromo перезагрузите сервер. Чтобы убедиться, что с новым сервером все в порядке, откройте командную строку и запустите утилиту Dcdiag. Если DNS и другие важные компоненты AD настроены верно, последовательность тестов будет выполнена успешно.

Перед запуском Dcdiag нужно очистить журналы событий System и DFS Replication, чтобы не получать сообщения о сбоях из-за сообщений об ошибках в ходе организации домена. Например, ошибки репликации DFS обычно регистрируются при первом запуске Dcdiag на новом контроллере домена (DC). Однако их появление не обязательно свидетельствует о неполадках DNS, которые часто оказываются причиной отказов репликации. После очистки журналов событий запустите команду

dcdiag/test: dfsrevent

Тест должен завершиться успешно.

Пока не задан источник времени, будут наблюдаться ошибки службы W32tm (служба Windows Time) в ходе проверок Dcdiag для контроллера корневого домена. Сведения о настройке службы Windows Time приведены в статье Microsoft «How to configure an authoritative time server in Windows Server» по адресу support.microsoft.com/kb/816042.

Корневые ссылки

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

Чтобы увидеть корневые ссылки, загруженные из файла cache.dns, откройте оснастку DNS из раздела Administrative Tools в меню Start. В консоли DNS щелкните правой кнопкой мыши на сервере DNS в левой области и выберите пункт Properties. В диалоговом окне свойств сервера перейдите на вкладку Root Hints (экран 1).

Экран 1. Просмотр корневых ссылок

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

Итеративные и рекурсивные запросы

Запросы, сделанные сервером DNS для преобразования имен с использованием корневых ссылок, — итеративные, то есть принимается лучший ответ (который может быть ссылкой на сервер имен, расположенный на более низких ступенях иерархии и способный определенно разрешить запрос). Иное дело DNS-клиент Windows, который направляет рекурсивные запросы серверу DNS, требуя определенного ответа или ошибки с сообщением, что данный ресурс не существует. Рекурсивные запросы обычно направляются клиентами DNS или серверами пересылки.

Настройка конфигурации дочернего домена

После успешной проверки преобразования внутренних и интернет-имен в корневом домене, можно добавить дочерний домен с именем HR (HR.ADcompany.com), в котором будут находиться все ресурсы. Зарегистрируйтесь на втором компьютере Server 2008 R2 в качестве локального администратора и убедитесь, что ему назначено подходящее имя, например DC2. Назначьте IP-адрес и маску подсети, затем задайте основной сервер DNS для сетевого адаптера сервера, указав IP-адрес контроллера домена в корневом домене. После запуска Dcpromo должны быть обнаружены корневой домен DNS и контроллер домена, поэтому необходимо настроить сервер DNS, способный ответить на эти запросы.

Прежде чем начать, выполните команду

dcdiag/test: dcpromo/dnsdomain: HR . ADcompany.com/ChildDomain

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

Запустите Dcpromo из меню Start, на этот раз чтобы создать новый домен в существующем лесу. На экране Network Credentials введите лес домена (ADcompany.com) и учетную запись, имеющую членство в группе Enterprise Administrators в корневом домене (экран 2). В диалоговом окне Name the New Domain введите полное имя FQDN корневого домена (ADcompany.com) и однокомпонентное имя для нового дочернего домена (HR), как показано на экране 3. В диалоговом окне Additional Domain Controller Options выберите DNS server. На остальных этапах принимайте параметры по умолчанию.

Экран 2. Создание нового домена в существующем лесу

Экран 3. Назначение имени новому домену

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

Откройте командную строку и выполните

ipconfig/all

Обратите внимание, что основной сервер DNS сетевого адаптера сервера настроен на локальный адрес сервера, а IP-адрес сервера DNS корневого домена смещен для использования в качестве дополнительного сервера DNS.

Делегирование и пересылка

Продолжая работать из командной строки, проверьте, можно ли установить связь с контроллером домена в корневом домене, используя однокомпонентное имя контроллера домена (DC1) или полное имя (DC1.ADcompany.com). При наличии подключения к Интернету должна существовать связь с именем домена в Интернете из дочернего DC домена. С контроллера корневого домена проверьте связь с DC в дочернем домене. Сервер DNS в дочернем домене направляет запросы к ресурсам ADcompany.com на сервер пересылки, автоматически настраиваемый в ходе выполнения Dcpromo. Увидеть конфигурацию можно, открыв консоль сервера DNS на контроллере дочернего домена из раздела Administrative Tools меню Start. В консоли DNS щелкните правой кнопкой мыши сервер в левой панели и выберите пункт Properties. В диалоговом окне свойств перейдите на вкладку Forwarders; видно, что сервер настроен на пересылку всех запросов, которые не удается обработать, на сервер DNS корневого домена. Пересылаются как внутренние, так и интернет-запросы; в этом отличие от сервера условной пересылки, настроенного на пересылку запросов, которые не удается обработать локально, только для определенного пространства имен.

В противоположность этому, на сервере DNS корневого домена находится запись делегирования (иногда именуемая зоной делегирования) для домена HR. Запись также настраивается как часть процесса Dcpromo для контроллера дочернего домена и позволяет контроллеру корневого домена обнаружить ресурсы в дочернем домене. Откройте консоль DNS на контроллере корневого домена; в левой панели разверните узлы DNS Server, Forward Lookup Zones, ADCompany.com. Щелкните зону делегирования HR в нижней части дерева. В правой панели находится запись типа A узла для сервера DNS дочернего домена. Делегирование и пересылка — стандартные механизмы Windows Server для преобразования в верхних и нижних областях непрерывного пространства имен DNS, как показано на рисунке 2.

Рисунок 2. Делегирование и пересылка

Регрессирование DNS

Регрессирование DNS — функция DNS-клиента Windows. Это не новшество Server 2008 R2 или Windows 7, однако таким образом удается повысить уровень безопасности. С контроллера дочернего домена можно проверить связь с ресурсами в корневом домене, не указывая имя FQDN (то есть связаться с DC1, не вводя DC1.ADcompany.com). То же относится к DC корневого домена; можно успешно проверить связь с DC2 без имени FQDN.

По умолчанию в ходе регрессирования предпринимается попытка преобразовать однокомпонентное имя, добавляя домены из основного суффикса DNS (PDS) клиента. Поэтому компьютер, принадлежащий домену AD.contoso.com, в первую очередь попытается разрешить имя компьютера как DC1.AD.contoso.com, а затем DC1.contoso.com. Попытки разрешить DC1.com не будет, так как уровень регрессирования по умолчанию — 2 (стандартное значение в Windows до появления Server 2008 R2 и Windows 7). В некоторых ситуациях уровень по умолчанию 2 порождает опасения в отношении безопасности, если клиенты DNS пытаются преобразовать полные имена (FQDN) за пределами контроля компании. Например, рассмотрим следующий набор запросов при уровне регрессирования, равном 2: DC1.HR.company.co.us, DC1.company.co.us, DC1.co.us. Последний запрос, DC1.co.us, находится вне области контроля компании, и клиент может случайно установить связь с вредоносным компьютером в Интернете.

В Server 2008 R2 и Windows 7 действие по умолчанию — установить уровень регрессирования равным количеству меток в корневом домене леса (FRD), если PDS завершается корневым доменом леса. В данном случае PDS — HR.ADcompany.com, а корневой домен леса — ADcompany.com, поэтому по умолчанию в Server 2008 R2 и Windows 7 регрессирование включено, а уровень для клиентов DNS установлен равным 2. Компания Microsoft выпустила обновление, чтобы изменить подход к регрессированию DNS в Windows Vista, Windows XP и Windows 2000. Дополнительные сведения об обновлении можно найти в статье Microsoft «Postinstallation behavior on client computers after you install the DNS update» по адресу support.microsoft.com/kb/957579.

Порядок просмотра суффиксов DNS

Если добавить в лес третий домен, finance.ADcompany.com, регрессирование DNS может оказаться недостаточным для преобразования однокомпонентных имен ресурсов в HR.ADcompany.com от клиентов в домене FINANCE. Преобразование однокомпонентного имени совершается из домена FINANCE, если попытаться обратиться к ресурсам в домене HR, когда все устройства находятся в одной физической подсети. Это объясняется тем, что Windows выполняет широковещательную передачу для IP-адреса, если не удается успешно преобразовать имя из локального кэша компьютера или настроенного сервера DNS.

Если использовать Nslookup для тестирования разрешения DNS, выясняется, что без просмотра суффиксов DNS необходимо ввести полное имя ресурса, расположенного в домене HR, поскольку Nslookup, как инструмент для тестирования преобразования имен DNS, использует исключительно DNS. Чтобы протестировать DNS с помощью Nslookup, откройте командную строку из меню Start и введите nslookup.

В ответ на приглашение введите полное или однокомпонентное имя, которое нужно преобразовать, и нажмите клавишу Enter. Nslookup выдаст IP-адрес или сообщит о неудачном завершении поиска.

Если разрешение однокомпонентных имен во всех доменах AD имеет большое значение, то можно настроить порядок просмотра суффиксов DNS на всех устройствах, составив список всех основных суффиксов DNS, которые нужно разрешать (например, finance.ADcompany.com, HR.ADcompany.com и ADcompany.com). Если суффикс DNS настроен для клиента DNS, регрессирование DNS автоматически отключается. Порядок просмотра можно настроить вручную (выберите Change adapter settings в центре управления сетями и общим доступом Windows 7) для каждого сетевого адаптера на вкладке DNS в диалоговом окне Advanced TCP/IP Settings для свойств IPv6 и IPv4. Иначе порядок просмотра можно настроить с использованием списка с разделительными запятыми из параметра DNS Suffix Search List в разделе Computer Configuration, Policies, Administrative Templates, Network, DNS Client in Group Policy (для Windows Server 2003, XP и более поздних версий).

Аналогично, если сформировать новую зону DNS, secure.HR.ADcompany.com, на сервере DNS HR с целью создания отдельной зоны для важных ресурсов сервера, защищенных с использованием расширений безопасности DNS (DNSSEC), то необходимо установить порядок просмотра суффикса DNS, чтобы клиенты DNS могли обнаружить ресурсы в новой зоне по однокомпонентному имени. В этом случае требуется новая зона DNS, так как DNSSEC не поддерживает динамические обновления — возможность клиентов хранить записи для автоматического обновления сервера, что является обычным и желательным режимом зон DNS, в которых хранятся записи узлов для клиентских компьютеров.

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

Условная пересылка

Кроссдоменные запросы для двух дочерних доменов, finance.ADcompany.com и HR.ADcompany.com, можно разрешать более эффективно, не отправляя рекурсивные запросы в сервер DNS в корневом домене леса, если настроить условную пересылку на серверах DNS в обоих дочерних доменах. Условная пересылка имеет приоритет перед пересылкой на уровне сервера. Ее эффективность выше благодаря возможности передавать запросы к определенным доменным суффиксам на заранее определенный сервер DNS, как показано на рисунке 3.

Рисунок 3. Условная пересылка

Сервер DNS в HR.ADcompany.com будет содержать сервер пересылки, который отправляет все запросы для finance.ADcompany.com на основной сервер DNS для домена FINANCE и наоборот. Для настройки условной пересылки откройте консоль DNS на контроллере домена в домене HR из раздела Administrative Tools меню Start. В левой панели консоли DNS разверните DNS server, щелкните правой кнопкой мыши Conditional Forwarders и выберите из меню пункт New Conditional Forwarder. В диалоговом окне New Conditional Forwarder введите finance.adcompany.com в поле DNS Domain. В поле IP addresses of the master servers введите IP-адрес или имя сервера DNS в домене FINANCE и нажмите клавишу Enter. Нажмите кнопку OK, затем повторите процесс на сервере DNS в домене FINANCE, но укажите HR.ADcompany.com в поле DNS Domain и IP-адрес сервера DNS в домене HR.

Сложности DNS

В одной статье невозможно всесторонне рассмотреть проблему. Например, существуют два типа зон, дополнительные и зоны-заглушки, с помощью которых можно повысить производительность, а также новая функция Server 2008 R2, такая как DNSSEC. Но понимание основ совместной работы DNS и AD в интегрированном решении поможет более успешно развертывать AD и выполнять диагностику. Главное, в ходе тестирования новой или существующей инфраструктуры AD убедитесь, что каждый домен может обращаться к ресурсам во всех доверенных доменах. Кроме того, организуйте делегирование и условную пересылку для разрешения между пространствами имен. Соблюдение этих основных правил поможет более эффективно использовать DNS в сложной среде AD.

Рассел Смит ([email protected]) — независимый ИТ-консультант, специализируется на управлении системами