Windows server dns динамическое обновление

У нас проблема возникла с дублированием записей в обратной зоне PTR DNS. Но для нас не было проблем что они там дублируются . Но после того как внедрили fortigate. Начались проблемы с интернетом. Он там хитро трафик делит. И смотрит в днс.

Решили настроить динамическое обновление dns через DHCP.

Сначала создали учётку srv.dnsupd для доступа dns. И добавили её в группу DnsUpdateProxy.

Настройка DNS.

Включить автоматическую очистку устаревших записей. Оставим по умолчанию 7 дней так как у нас dhcp аренда 8 дней.

Войдите в клиентскую среду и нажмите > > > > .
Щелкните правой кнопкой мыши соответствующий DNS-сервер и выберите « .
Убедитесь, что выбрано .
Установите интервал без обновления и интервал обновления, чтобы общая продолжительность была равна или меньше срока аренды DHCP, и нажмите кнопку .
Например, если срок аренды DHCP составляет 8 дней , значение по умолчанию для каждого поля может составлять 4 дня или меньше.
Выберите , и нажмите .
Щелкните правой кнопкой мыши соответствующий DNS-сервер и выберите « .

В заданный период времени сервер выполняет поиск записей DNS и удаляет устаревшую информацию.

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

Чтобы настроить динамическое обновление DNS для DHCP-сервера под управлением Windows Server 2003, выполните следующие действия:

Нажмите « Пуск» , выберите «
Администрирование» и нажмите «
DHCP» .
Щелкните правой кнопкой мыши соответствующий DHCP-сервер или область и выберите « Свойства» .
Щелкните DNS .
Enable DNS dynamic updates according to the settings below” – включен по умолчанию, и у вас есть два варианта выбора, как показано ниже
Dynamically update DNS A and PTR records only if requested by the DHCP clients – Это выбор по умолчанию. Этот параметр означает, что ваш DHCP-сервер будет обновлять записи DNS для клиентов только в том случае, если клиенты по какой-либо причине не могут выполнить обновление. Как указано ниже, это может работать некорректно, особенно если клиенты не являются компьютерами под управлением Windows.
Always dynamically update DNS A and PTR records – Теперь вы должны изменить выбор на эту опцию. Что произойдет, так это то, что DHCP-сервер выполнит обновление независимо от того, может это сделать клиент или нет.
Теперь вы также можете заметить, что на той же вкладке в свойствах DHCP-сервера есть несколько других параметров. Приведенное ниже объяснение расскажет вам о функциях каждой опции и о том, что вам нужно с ними делать:
- Discard A and PTR records when lease is deleted — Как следует из названия, он удалит ранее зарегистрированные записи A и PTR при удалении аренды DHCP для соответствующего клиента. Установите флажок, чтобы включить эту опцию, так как это поможет очистить неиспользуемые записи на DNS-сервере.
- Dynamically update DNS records for DHCP clients that do not request for updates — Эта опция присутствует только в том случае, если у вас есть очень старая машина или машина не под управлением Windows в качестве DHCP-клиента, который не выполняет динамическое обновление своей собственной записи на DNS-сервере. Установите флажок, чтобы включить эту опцию, и заставьте DHCP-сервер выполнить обновление DNS для них.
- Disable dynamic updates for PTR records — Когда вы активируете эту опцию, ваш DHCP-сервер будет выполнять только динамическое обновление для записей A. Вам решать, что делать с этой опцией, но в этом примере мы не устанавливаем галочку для этой опции и позволяем DHCP-серверу также управлять записями PTR.
Щелкните ОК .

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

Добавьте DHCP-сервер в группу безопасности DnsUpdateProxy.

В документации пишут :Если DHCP-сервер находится на другом компьютере, чем контроллер домена, убедитесь, что DHCP-сервер включен в группу DnsUpdateProxy в Active Directory . В противном случае DHCP-сервер не сможет обновлять записи на DNS-сервере.
Но у меня так не заработала на 2016 windows. Я добавил в группу еще контролеры домена. Тогда все норм стало.

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff631099(v=ws.10)?redirectedfrom=MSDN

Включим также Защита имени DHCP – это функция службы DHCP, которая при использовании с динамической регистрацией DNS не позволяет клиенту DHCP с именем, уже находящимся в зоне домена DNS, регистрировать или перезаписывать существующее имя, которым он не владеет. Эта функция предотвращает спуфинг клиента и сервера и повреждение имен для статически настроенных систем, уже зарегистрированных в DNS. Вы можете включить защиту имени на уровне узла IPv4 или IPv6 или на уровне области. При настройке на уровне области параметры имеют приоритет над параметрами узла IPv4 или IPv6.

Что касается использования группы DnsUpdateProxy, я понимаю, что в эту группу должны входить только DHCP-серверы, а не пользователь динамического обновления DNS. Предполагается, что учетная запись пользователя будет добавлена в конфигурацию DHCP-сервера, а не в группу DnsUpdateProxy.
Группа DnsUpdateProxy предназначена для клиентов DNS. Пользователь не является клиентом, это механизм, используемый клиентом (DHCP-сервером) для динамического обновления DNS, когда включены только безопасные обновления. Клиент остается сервером DHCP.
Когда DHCP-сервер находится на контроллере домена, помимо того, что он входит в группу и добавляет пользователя в конфигурацию DHCP, вам также необходимо отключить OpenACLOnProxyUpdates. Если вы этого не делаете, вы добавляете уязвимость, потому что членство в группе DnsUpdateProxy дает слишком много полномочий над записями DNS.
Некоторые школы считают, что DHCP на контроллере домена не должен быть членом DnsUpdateProxy, а только для пользователя обновления DNS должен быть назначен DHCP. Это может быть верно для более старых версий Windows Server, но для 2012R2 и более поздних версий у меня есть чувство из технических документов, что сервер все еще должен быть в группе DnsUpdateProxy, но из-за того, что он является DC, разрешения членства в этой группе открывают уязвимость.

Итак, если у вас есть DHCP на контроллере домена с включенным безопасным динамическим обновлением DNS, вы должны также выполнить эту команду на контроллере домена, на котором работает DHCP, чтобы его DNS не позволял «чужим» обновлениям изменять записи, принадлежащие DHCP:

dnscmd / config / OpenAclOnProxyUpdates 0

Итог – группа DnsUpdateProxy не предназначена для какого-либо пользовательского объекта – она должна использоваться только для объектов DHCP-сервера (клиентов DHCP) и в первую очередь предназначена для «наилучшей практики» размещения вашего DHCP-сервера на сервере без DC, чтобы передать необходимые разрешения для динамического обновления DNS. Добавление пользователя защищенного обновления в эту группу не имеет смысла.

Показать текущее состояние:

dnscmd /info / penACLOnProxyUpdates

Желаемое состояние:

dnscmd /config /OpenAclOnProxyUpdates 0

Вернуться к умолчанию:

dnscmd /config /OpenAclOnProxyUpdates 1

Укажите учетные данные для защиты динамического обновления DNS.

Это применимо, если зона DNS, в которой ваш DHCP-сервер будет регистрировать / обновлять записи, является зоной, интегрированной в Active Directory, которая допускает только безопасные динамические обновления .

Вам необходимо указать учетную запись пользователя в свойствах DHCP-сервера . Откройте вкладку « Дополнительно » в свойствах DHCP-сервера и нажмите кнопку « Учетные данные» .

Введите имя пользователя, домен и пароль в доступное поле.
Обратите внимание, что учетная запись может быть учетной записью обычного пользователя без каких-либо специальных привилегий, но она должна существовать в том же лесу, что и DNS-сервер . Вы также можете использовать учетную запись пользователя из другого леса, если его лес установил доверие леса с лесом, в котором находится DNS-сервер.
Таким образом, DHCP-сервер будет по-прежнему арендовать IP-адрес, но не будет создавать DNS-запись, если запись с таким именем уже существует .
Что ж, это почти все, что вам нужно для настройки динамического обновления DNS на DHCP-сервере Windows. С этого момента ваш DHCP-сервер будет заботиться о записях DNS для своих клиентов. DHCP-сервер будет регистрировать и обновлять записи для своих клиентов , а также удаляет записи об истекших сроках аренды . Это гарантирует, что DNS-сервер не будет заполнен записями о неактивных клиентах. Кроме того, вы также можете настроить устаревание и очистку в зоне DNS в соответствии со временем аренды DHCP, и это поможет очистить неиспользуемые записи.

Поиск одинаковых записей с одним IP

#Import the Active Directory Module
import-module activedirectory

#Define an empty array to store computers with duplicate IP address registrations in DNS
$duplicate_comp = @()

#Get all computers in the current Active Directory domain along with the IPv4 address
#The IPv4 address is not a property on the computer account so a DNS lookup is performed
#The list of computers is sorted based on IPv4 address and assigned to the variable $comp
$comp = get-adcomputer -filter * -properties ipv4address | sort-object -property ipv4address

#For each computer object returned, assign just a sorted list of all
#of the IPv4 addresses for each computer to $sorted_ipv4
$sorted_ipv4 = $comp | foreach {$_.ipv4address} | sort-object

#For each computer object returned, assign just a sorted, unique list
#of all of the IPv4 addresses for each computer to $unique_ipv4
$unique_ipv4 = $comp | foreach {$_.ipv4address} | sort-object | get-unique

#compare $unique_ipv4 to $sorted_ipv4 and assign just the additional
#IPv4 addresses in $sorted_ipv4 to $duplicate_ipv4
$duplicate_ipv4 = Compare-object -referenceobject $unique_ipv4 -differenceobject $sorted_ipv4 | foreach {$_.inputobject}

#For each instance in $duplicate_ipv4 and for each instance
#in $comp, compare $duplicate_ipv4 to $comp If they are equal, assign
#the computer object to array $duplicate_comp
foreach ($duplicate_inst in $duplicate_ipv4)
{
    foreach ($comp_inst in $comp)
    {
        if (!($duplicate_inst.compareto($comp_inst.ipv4address)))
        {
            $duplicate_comp = $duplicate_comp + $comp_inst
        }
    }
}

#Pipe all of the duplicate computers to a formatted table
$duplicate_comp | ft name,ipv4address -a

Step 1 – Set DHCP server to always dynamically update records

You can start configure DNS dynamic update in Windows DHCP server by opening the DHCP console. Expand the server name > right-click on IPv4 > select Properties > DNS tab.

You’ll see by default on Windows Server 2012 R2 the option to “Enable DNS dynamic updates according to the settings below” is enabled by default and you have two selection options as follow:

Dynamically update DNS A and PTR records only if requested by the DHCP clients – This is the default selection. This setting means that your DHCP server will only update DNS records for the clients only if the clients for some reason unable to perform the update. As stated below, this may not work correctly, especially if the clients are non-Windows machine.
Always dynamically update DNS A and PTR records – Now you must change the selection to this option. What will happen is the DHCP server will perform the update regardless the client is able to do it or not.

Now you may also notice there are several other options in the same tab in DHCP server properties. The explanation below will tell you the function of each option and what you need to do with them:

Discard A and PTR records when lease is deleted — As the name implies, it will delete the previously registered A and PTR record when the DHCP lease for the corresponding client is deleted. Tick the box to enable this option as it will help clean-up unused records in the DNS Server.
Dynamically update DNS records for DHCP clients that do not request for updates — This option is present just in case you have a very old machine or non-Windows machine as DHCP client that do not perform dynamic update of its own record in the DNS server. Tick the box to enable this option and force the DHCP server to perform DNS update for them.
Disable dynamic updates for PTR records — When you active this option, your DHCP server will only perform the dynamic update for A records. It’s up to you on what to do with this option, but in this example we don’t tick the box for this option and let the DHCP server to also manage the PTR records.

With all the things configured here, we actually have set the DHCP server to take ownership of all its client records in the DNS server. However, we’re still far from done as there are few additional steps that we must do.

Step 2 — Add the DHCP server to DnsUpdateProxy security group

If the DHCP server is on a different machine than the Domain Controller, make sure to include the DHCP server in the DnsUpdateProxy group in Active Directory (see figure below). Otherwise, the DHCP server will not be able to update the records on DNS server.

Step 3 – Provide credential to secure the DNS dynamic update

This applies if the DNS zone where your DHCP server will register/update records is an Active Directory-integrated zone which allows only secure dynamic updates.

You need to provide a user account in the DHCP server properties. Open the Advanced tab of the DHCP server properties and click the Credentials button.

Fill in the username, domain, and password in the available field.

Note that the account can be a regular user account without any special privilege but it must exist in the same forest as the DNS server. You can also use user account from different forest, as long as its forest has established a forest trust with the forest where the DNS server resides.

Step 4 — Configure name protection

Since we’re enabling the “Dynamically update DNS records for DHCP clients that do not request for updates” option, means that we’re allowing non-domain machine or non-Windows machine to have their records as well in the DNS server. There is a chance such machine has the same host name with other existing machine in the network. If this happen, this could cause confusion in the name resolution.

To prevent such issue, we can activate the DHCP name protection. Back to the DNS tab in DHCP server option, under Name Protection > click Configure.

Tick the box to Enable Name Protection.

With this way, DHCP server will still lease the IP address normally but will not create the DNS record if a record with the same name already exists.

Well, that’s pretty much all the stuffs you need to configure DNS dynamic update in Windows DHCP server. From now, your DHCP server will take care of DNS records for its clients. DHCP server will register and update records for its clients, and will also delete the record for expired leases. This will ensure that DNS server will not be filled up with records for inactive clients. Additionally, you can also configure aging and scavenging in the DNS zone to match the DHCP lease time and this will help clean up the unused records.

The following two tabs change content below.

Bio
Latest Posts

I am IT practitioner in real life with specialization in network and server infrastructure. I have years of experience in design, analysis, operation, and optimization of infrastructure solutions for enterprise-scaled network. You can send me a message on LinkedIn or email to arranda.saputra@outlook.com for further inquiry regarding stuffs that I wrote or opportunity to collaborate in a project.

Источник

В данном руководстве подробно описан и продемонстрирован процесс настройки DNS-сервера на Windows Server 2012 R2.

Для настройки DNS-сервера на Windows Server 2012 R2 потребуются:

1. Компьютер, под управлением Windows Server 2012 R2 (О том как установить Windows Server 2012 R2 можно прочитать в данной статье: «Установка и активация Windows Server 2012 R2 с USB флешки» );

2. Установленная и настроенная роль Active Directory Domain Services (контроллер домена) на Windows Server 2012 R2 (О том как установить Active Directory Domain Services можно прочитать в данной статье: «Установка контроллера домена Active Directory в Windows Server 2012 R2» ).

Порядок настройки DNS-сервера на Windows Server 2012 R2

1. Откройте окно диспетчера сервера, затем нажмите Средства и выберите из списка пункт DNS (Рис.1).

Рис.1

2. В меню Действие выберите пункт Настроить DNS-сервер… (Рис.2).

Рис.2

3. На странице приветствия мастера настройки DNS-сервера щелкните на кнопке Далее (Рис.3).

Рис.3

4. Выберите пункт Создать зоны прямого и обратного просмотра (рекомендуется для больших сетей) и щелкните на кнопке Далее (Рис.4).

Рис.4

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

Рис.5

6. Выберите тип зоны Основная зона, установите галочку напротив Сохранять зону в Active Directory, затем нажмите Далее (Рис.6).

Рис.6

7. Выберите пункт Для всех DNS-серверов, работающих на контроллерах домена в этом домене (прим. в данном руководстве используется домен с названием example.local), затем нажмите Далее (Рис.7).

Рис.7

8. Введите имя зоны (прим. в данном руководстве используется имя example.local), затем нажмите Далее (Рис.8).

Рис.8

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

Рис.9

10. Выберите пункт Да, создать зону обратного просмотра сейчас и нажмите Далее (Рис.10).

Рис.10

11. Выберите тип зоны Основная зона, установите галочку напротив Сохранять зону в Active Directory, затем нажмите Далее (Рис.11).

Рис.11

12. Выберите пункт Для всех DNS-серверов, работающих на контроллерах домена в этом домене (прим. в данном руководстве используется домен с названием example.local), затем нажмите Далее (Рис.12).

Рис.12

13. Выберите пункт Зона обратного просмотра IPv4, затем нажмите Далее (Рис.13).

Рис.13

14. Введите идентификатор сети для зоны обратного просмотра и нажмите Далее (прим. как правило, в качестве сетевого идентификатора вводится первый набор октетов из IP-адреса зоны. Например, если в сети используется диапазон IP-адресов класса С 192.168.0.0/24, то в качестве сетевого идентификатора могут быть введено значение 192.168.0.) (Рис.14).

Рис.14

15. Выберите Запретить динамические обновления, затем нажмите Далее (Рис.15).

Рис.15

16. В настройках пересылки выберите пункт Нет, не пересылать запросы, затем нажмите Далее (Рис.16).

Рис.16

17. Для сохранения выбранных параметров настройки нажмите Готово (Рис.17).

Рис.17

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

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

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

Как настроить DNS-сервер:

Настройка сетевого адаптера для DNS-сервера
Установка роли DNS-сервера
Создание зоны прямого просмотра
Создание зоны обратного просмотра
Создание A-записи
Описание функции Domain Name System (DNS), которые являются новыми или измененными в Windows Server 2016.

Установка 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).

Описание функции Domain Name System (DNS), которые являются новыми или измененными в Windows Server 2016.

В Windows Server 2016 DNS-сервер предлагает обновления в следующих областях:

Политики DNS-серверов
Ограничение скорости отклика (RRL)
Аутентификация именованных объектов на основе DNS (DANE)
Поддержка неизвестных записей
Корневые подсказки IPv6
Доработка поддержки Windows PowerShell

Политики DNS-серверов

Теперь вы сможете использовать:

DNS-политики для управления трафиком на основе геолокации
Интеллектуальные ответы DNS в зависимости от времени суток, для управления одним DNS-сервером, настроенным для развертывания с разделением
Применять фильтры к DNS-запросам и многое другое.

Конкретное описание данных возможностей:

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

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

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

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

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

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

Вы также можете использовать политики DNS для зон DNS, интегрированных с Active Directory.

Ограничение скорости отклика (RRL)

Теперь вы cможете настроить параметры RRL, чтобы контролировать, как отвечать на запросы к DNS-клиенту, когда ваш сервер получает несколько запросов, направленных на одного и того же клиента. Сделав это, вы можете предотвратить отправку атаки типа «Отказ в обслуживании» (Dos) с использованием ваших DNS-серверов.
Например, бот-сеть может отправлять запросы на ваш DNS-сервер, используя в качестве отправителя IP-адрес третьего компьютера. Без RRL ваши DNS-серверы могут отвечать на все запросы, переполняя третий компьютер. При использовании RRL вы можете настроить следующие параметры:

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

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

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

Скорость утечки. Это то, как часто DNS-сервер отвечает на запрос во время приостановки ответов. Например, если сервер приостанавливает ответы клиенту на 10 секунд, а уровень утечки равен 5, сервер по-прежнему отвечает на один запрос на каждые 5 отправленных запросов. Это позволяет обычным клиентам получать ответы, даже если DNS-сервер применяет ограничение скорости ответов в их подсети или полном доменном имени.

TC rate. Эта функция используется, чтобы сообщить клиенту о попытке соединения с TCP, когда ответы клиенту приостановлены. Например, если скорость TC равна 3, и сервер приостанавливает ответы данному клиенту, сервер выдает запрос на TCP-соединение для каждых 3 полученных запросов. Убедитесь, что значение скорости TC ниже, чем скорость утечки, чтобы дать клиенту возможность подключиться через TCP перед утечкой ответов.

Максимум откликов. Это максимальное количество ответов, которые сервер выдает клиенту, пока ответы приостановлены.

Белые домены. Это список доменов, которые нужно исключить из настроек RRL.

Белые подсети. Это список подсетей, которые необходимо исключить из настроек RRL.

Интерфейсы серверов белого списка. Это список интерфейсов DNS-серверов, которые необходимо исключить из настроек RRL.

Аутентификация именованных объектов на основе DNS (DANE)

Теперь вы сможете использовать поддержку DANE (RFC 6394 и 6698), чтобы указать своим DNS-клиентам, от какого CA они должны ожидать выдачи сертификатов для доменных имен, размещенных на вашем DNS-сервере.
Это предотвращает форму атаки «main in the middle», когда кто-то может повредить кэш DNS и указать DNS-имя на свой собственный IP-адрес.

Поддержка неизвестных записей

«Неизвестная запись» — это RR, формат RDATA которой неизвестен DNS-серверу. Недавно добавленная поддержка неизвестных типов записей (RFC 3597) означает, что вы cvожете добавлять неподдерживаемые типы записей в зоны DNS-сервера Windows в двоичном формате по сети.
Распознаватель кэширования Windows уже имеет возможность обрабатывать неизвестные типы записей. DNS-сервер Windows не выполняет никакой конкретной обработки неизвестных записей, но отправляет их обратно в ответах, если для них получены запросы.

Корневые подсказки IPv6

Корневые подсказки IPV6, опубликованные IANA, были добавлены на DNS-сервер Windows. Запросы имен в Интернете теперь могут использовать корневые серверы IPv6 для разрешения имен.

Доработка поддержки Windows PowerShell

В Windows Server 2016 представлены следующие новые командлеты (cmdlets) и параметры Windows PowerShell:

Add-DnsServerRecursionScope — Этот командлет создает новую область рекурсии на DNS-сервере. Области рекурсии используются политиками DNS для указания списка серверов пересылки, которые будут использоваться в запросе DNS.

Remove-DnsServerRecursionScope — Этот командлет удаляет существующие области рекурсии.

Set-DnsServerRecursionScope — Этот командлет изменяет параметры существующей области рекурсии.

Get-DnsServerRecursionScope — Этот командлет извлекает информацию о существующих областях рекурсии.

Add-DnsServerClientSubnet — Этот командлет удаляет существующие подсети DNS-клиентов.

Set-DnsServerClientSubnet — Этот командлет изменяет параметры существующей подсети DNS-клиента.

Get-DnsServerClientSubnet — Этот командлет извлекает информацию о существующих подсетях DNS-клиентов.

Add-DnsServerQueryResolutionPolicy — Этот командлет создает новую политику разрешения запросов DNS. Политики разрешения запросов DNS используются для указания того, как и следует ли отвечать на запрос на основе различных критериев.

Remove-DnsServerQueryResolutionPolicy — Этот командлет удаляет существующие политики DNS.

Set-DnsServerQueryResolutionPolicy — Этот командлет изменяет параметры существующей политики DNS.

Get-DnsServerQueryResolutionPolicy — Этот командлет извлекает информацию о существующих политиках DNS.

Enable-DnsServerPolicy — Этот командлет включает существующие политики DNS.

Disable-DnsServerPolicy — Этот командлет отключает существующие политики DNS.

Add-DnsServerZoneTransferPolicy — Этот командлет создает новую политику передачи зоны DNS-сервера. Политики передачи зоны DNS определяют, следует ли отклонять или игнорировать передачу зоны на основе различных критериев.

Remove-DnsServerZoneTransferPolicy — Этот командлет удаляет существующие политики передачи зон DNS-сервера.

Set-DnsServerZoneTransferPolicy. — Этот командлет изменяет параметры существующей политики переноса зоны DNS-сервера.

Get-DnsServerResponseRateLimiting — Этот командлет извлекает параметры RRL.

Set-DnsServerResponseRateLimiting — Этот командлет изменяет настройки RRL.

Add-DnsServerResponseRateLimitingExceptionlist — Этот командлет создает список исключений RRL на DNS-сервере.

Get-DnsServerResponseRateLimitingExceptionlist — Этот командлет извлекает списки исключений RRL.

Remove-DnsServerResponseRateLimitingExceptionlist — Этот командлет удаляет существующий список исключений RRL.

Set-DnsServerResponseRateLimitingExceptionlist — Этот командлет изменяет списки исключений RRL.

Add-DnsServerResourceRecord — Этот командлет был обновлен для поддержки неизвестного типа записи.

Get-DnsServerResourceRecord — Этот командлет был обновлен для поддержки неизвестного типа записи.

Remove-DnsServerResourceRecord — Этот командлет был обновлен для поддержки неизвестного типа записи.

Set-DnsServerResourceRecord — Этот командлет был обновлен для поддержки неизвестного типа записи.

С дополнительными сведениями вы можете ознакомится в следующих разделах справочника по командам Windows PowerShell для Windows Server 2016 от Microsoft:
Powershell DNS Server
Powershell DNS Client

Содержание

Понятие роли DNS Server
Установка DNS
Конфигурирование автономного DNS-cepвepa
Интеграция с другими DNS-серверами
Реализация зон для управления пространствами имен
Типы записей
Управление клиентами DNS и преобразованием имен
Система DNS в Active Directory
Автоматическое конфигурирование DNS
Записи SRV и клиенты
Дополнительные компоненты Windows Server 2012 R2
Поддержка преобразования имен DNS на основе Интернета
Поддержка внешних доменов DNS
Преобразование внешних пространств имен
Администрирование и устранение неполадок с помощью инструментов DNS
Администрирование DNS-cepвepa с помощью консоли управления DNS и PowerShell
Использование NsLookup и DcDiag
Полезные ссылки по устранению неполадок в DNS

Компьютеры взаимодействуют друг с другом с использованием IР-адресов,
либо 1 Pv4, либо 1 Pv6. Тем не менее, большинству людей трудно запомнить
IР-адрес излюбленного веб-сайта или файлового сервера. Людям нравится приме
нять дружественные текстовые имена. Таким образом, для преобразования этих дружественных имен компьютеров в назначенные им I Р-адреса реализуются системы имен. Система доменных имен (Domain Name System — DNS) — это система имен, используемая серверами Windows Server 2012 R2. Система DNS не только помогает пользователям легко идентифицировать устройства, она является обязательной для множества служб, таких как Active Directory, чтобы клиенты и серверы могли взаимодействовать с контроллерами доменов.
В этой главе вы изучите следующие темы:
• фундаментальные компоненты и процессы DNS;
• конфигурирование DNS для поддержки среды Active Directory;
• управление и устранение неполадок с преобразованием имен DNS для внут
ренних и внешних имен.

Система DNS существовала на протяжении десятилетий до того, как в Microsoft
разработали свою первую редакцию DNS в Windows NT 4.0. Существует много раз
новидностей реализаций DNS, которые поддерживают компоненты и процессы, определяющие DNS. В этом разделе мы раскроем концепции системы доменных имен от Microsoft и покажем, как она применяется в операционных системах Windows.
Система DNS реализована внутри ОС Windows Server 201 2 R2 для управления
преобразованием имен в I Р-адреса. После установки на сервере службе DNS по
надобится взаимодействовать с другими серверами имен DNS, что достигается с
использованием множества разных методов, таких как переадресация, корневые
подсказки и делегирование. Служба DNS будет также поддерживать базы данных,
называемые зонами, для внутреннего домена Active Directory или других пространств имен. Компьютерам домена необходимо будет опрашивать эту службу DNS, поэтому вам придется сконфигурировать отдельные компьютеры, чтобы обеспечить эффективное и быстрое преобразование имен.
Windows Server 2012 R2 и предыдушие выпуски ОС Windows Server предлагают
встроенную роль DNS Server (DNS-cepвep). Система Windows Server 201 2 R2 DNS
совместима со старыми версиями DNS вплоть до Windows Server 2003; однако версии, более ранние, чем Windows Server 2008, не поддерживают 1Pv6 и функционируют только с адресами IPv4.
Ниже приведена краткая сводка по фундаментальным концепциям DNS, имею
щим отношение к данной главе.
• Имя хоста (hostname). Это (дружественное) имя компьютера. Согласно стан
дартам DNS, оно может иметь длину до 255 символов. Имя хоста эквиваflент
но первому имени компьютера, например, ECOl.
• Пространство имен (namespace). Это имя домена, хотя и не обязательно доме
на Active Directory. Пространство имен представляет собой логический набор
хостов, обозначенных именем, которое управляется набором серверов имен.
Это эквивалент второго имени компьютера; все они являются частью одного
семейства. Например, Bigfirm. com — пространство имен для хостов в домене
Bigfirm. com.
• Полное имя домена (Fully Qualified Domain Name — FQDN). Ичя FQDN —
это имя хоста, к которому добаrшено пространство имен домена, такое как
ECOl . Bigfirm. com.
• Файл ноsтs. Это текстовый файл, в котором имена хостов статически отоб
ражаются на IР-адреса. Файл HOSTS расположен в с : windowssystem32
driversetc для стандартных установок Windows Server 2012 R2 и может при
меняться в качестве простейшей альтернативы DNS-cepвepy для преобразо
вания имен в небольших средах. Тем не менее, не пытайтесь управлять круп
ными производственными средами с помощью записей в статическом файле
ноsтs, поскольку это быстро превратится в кошмар администрирования!
• Сервер имен (name server). Это DNS-cepвep, который будет преобразовывать
имена FQDN в IР-адреса. Серверы имен также управляют пространствами
имен для указанных доменов. Они будут обрабатывать запросы для этих про
странств имен, поступающие от клиентов DNS через сеть.
• Иерархическая структура имен (blerarchical naming stгucture). Пространство имен создано, поэтому левой частью имени является подмножеством правой части
имени, как можно видеть в FQDN. С учетом этого сервера имен могут начи
нать с правой части имени, а ответы от серверов имен направят его на коррек
тный сервер имен для заданноrо пространства имен. Например, как показано
на рис. 6. 1 , Ес0 1 . Ecoast . Bigfirm. com является именем FQDN для сервера в домене Ecoast . Bigfirm. com. Данный домен в действительности представляет собой подмножество, или поддомен, находящееся под контролем домена Bigfirm. com. То же самое можно сказать
о Bigfirm. com в отношении имени доме
на верхнего уровня . com. Достоинство за
ключается в том, что вы можете запросить
у сервера доменных имен . com, где на
ходится сервер имен Bigfirm. com. То же
самое можно делать для сервера Ecoast .
Bigfirm. com и т.д. Имя FQDN направля
ет запрос правильному серверу имен пос
редством процесса, который называется
рекурсией.
Домен .com
Д о мен Bi g firm.com
+ Рекурсия (recursion). Это управляемый
сервером процесс преобразования имени
FQDN. Если сервер не может распознать
имя FQDN посредством собственной ин-
формации, он отправит запрос другим
Рис. 6.1 . Иерархическое именова-
ние DNS
серверам имен. В процесс рекурсии вовле-
чены корневые серверы и серверы имен доменов. Корневые серверы находят
ся на верхушке иерархической структуры имен. Корневые серверы содержат
списки серверов имен, которые управляют именами доменов верхнего уровня,
такими как . com, . gov и . edu. Серверы доменов верхнего уровня управля
ют реестром поддоменов, расположенных в иерархии ниже доменов верхнего
уровня. Например, серверы имен для поддомена Sybex. com зарегистрированы
на серверах домена . com. Н иже описаны действия, которые происходят при
поступлении запроса имени (рис. 6.2).
Корневой («.») DNS-cepвep
DNS-cepвep Sybex.com
www .Sybex.com
DNS-клиент
Рис. 6.2. Процесс рекурсии в DNS

. Клиент DNS запрашивает у DNS-cepвepa имя, подобное www . Sybex . com.
2. Через процесс рекурсии DNS-cepвep запрашивает у корневых серверов сер
веры имен домена . com.
3. Корневые серверы предостамяют список серверов имен Дll Я домена . com.
4. DNS-cepвep запрашивает у серверов домена . com серверы имен ДllЯ Sybex .
com.
5. Он получает еще один список серверов имен Дll Я домена Sybex. com.
6. DNS-cepвep запрашивает у предоставленных серверов имен FQDN-имя
www. Sybex . com.
7. DNS-cepвep Sybex . com выдает I Р-адрес веб-сервера исходному DNS
cepвepy.
8. Исходный DNS-cepвep передает IР-адрес клиенту.
9. Располагая этим 1 Р-адресом, клиент подключается к веб-серверу www .
Sybex . com.
• Делеrирование (delegation). Это означает разрешение другому серверу имен
управлять поддоменом заданного пространства имен. Например, серве
ры имен Bigfirm. com могут делегировать управление пространством имен
Ecoast . Bigfirm. com другому серверу.
• Переадресация (forwarding). Это является альтернативой процессу рекурсии.
Переадресация представляет собой ответвленный запрос к другому серверу
имен внугри сети. Сервер, на который бьша произведена переадресация, полу
чает ответ и ретранслирует его исходному серверу имен.
• Итерация (iteration). Это управляемый клиентом процесс преобразования име
ни FQDN. Если клиент получает отрицательный ответ от сервера имен, он бу
дет запрашивать другой сервер имен.
• Система имен NetBIOS (NetBIOS naming system). Эта унаследованная система
имен использовалась главным образом в старых сетях Microsoft NT 4.0. Тем не
менее, ее процессы по-прежнему являются частью современных операцион
ных систем Windows, особенно когда применяются компьютеры, входящие не
в домен, а в рабочую группу.
• Записи служб (service records). Записи служб (SRV) представляют собой записи
внутри пространства имен DNS, предназначенные мя преобразования службы
в имя хоста. Они являются неоrьемлемой частью поддержки DNS мя Active
Directory.
• Динамическое обновление DNS (dynamic DNS update). Динамическое обновле
ние DNS (Dynamic DNS — DDNS) — это процесс, который позволяет кли
ентам DNS регистрировать свои имена хостов в назначенном пространстве
имен, Т’Jком как DHCP. Это сокращает необходимость ручного ввода записей
администраторами в базы данных серверов имен. Динамическое обновление
DNS является еше одной неотъемлемой частью поддержки DNS для Active
Directory.

Установка DNS

Роль DNS для Windows Server 2012 R2 может быть развернута в нескольких отличающихся конфиrурациях, зависящих от выбранного сценария. Можно установить автономный DNS-cepвep на компьютере, не присоединенном к домену, или же можно развернуть его либо на серверах-членах домена, либо на серверах, являющихся контроллерами домена Active Directory. Какой бы сценарий не был выбран, установка роли DNS проста. Сначала мы покажем, что понадобится сделать для ручного развертывания DNS на компьютере, не присоединенном к домену, в автономной конфиrурации. Затем мы объясним, как автоматически сконфиrурировать DNS для интеграции с Active Directory, чтобы обеспечить гладкое выполнение преобразования имен внутри среды домена.

Конфигурирование автономного DNS-cepвepa

Самое важное: вы должны выделить серверу, на котором хотите установить
роль DNS, статический IР-адрес, поскольку попадать в движущуюся цель клиенту
DNS будет очень непросто! Если на рабочем столе вы нажмете комбинацию кла
виш <Ctrl+R>, а затем введете ncpa. cpl и нажмете , откроется окно Network
Connections (Подключения к сети). В этом окне можно щелкнуть правой кнопкой на сетевом адаптере и выбрать в контекстном меню пункт Properties (Свойства), чтобы открыть окно конфигурирования. Если вы дважды щелкнете на элементе lnternet Protocol Version 4 (TCP/1Pv4) (Протокол Интернета версии 4 ((TCP/1Pv4))), откроется
диалоговое окно lnternet Protocol Version 4 (TCP/1Pv4) Properties (Свойства протокола Интернета версии 4 (TCP/1Pv4)). В нем можно назначить статический IР-адрес, как показано на рис. 6.3.
После назначения статического 1 Р-адреса вы должны добавить первичный DNS
суффикс, такой как Bigf i rm . com, в диалоговом окне Advanced TCP/1Pv4 Settings
(Расширенные настройки TCP/1Pv4), как показано на рис. 6.4.

Добавление первичного DNS-суффикса требуется не всегда. Он модифицируется
автоматически, когда компьютер присоединяется к домену. Если по плану сервер
должен функционировать как часть рабочей группы (в рассматриваемом примере
так и есть), первичный DNS-суффикс необходимо добавить, чтобы другие DNS
cepвepы могли находить этот сервер внутри структуры DNS, а служба DNS была
корректно сконфигурирована во время установки.
После указания статического IР-адреса и DNS-суффикса на сервере, не при
соединенном к домену, выполните перечисленные ниже шаги для установки роли DNS.
l . Откройте диспетчер серверов щелкните на элементе Dashboard (Управляющая
панель) и затем щелкните на ссылке Add Roles and Features (Добавить роли и
компоненты),

2. На экране Before You Begin (Прежде чем начать) мастера добавления ролей и
компонентов (Add Roles and Features Wizard) щелкните на кнопке Next (Далее),
чтобы продолжить.
3. На экране Select lnstallation Туре (Выбор типа установки) выберите переклю
чатель Role-Based or Feature-Based installation (Установка на основе ролей или
на основе компонентов) и щелкните на кнопке Next.
4. На экране Select Destination Server (Выбор сервера назначения) мастера выберите переключатель Select а Server from the Server Pool (Выбрать сервер из пула серверов) и удостоверьтесь в том, что ваш сервер отмечен; щелкните на кнопке Next.
5. На экране Select Server Roles (Выбор серверных ролей) мастера отметьте флажок возле роли DNS Server (DNS-cepвep) и, если после выбора роли DNS
Server откроется диалоговое окно, щелкните в нем на кнопке Add Features
(Добавить компоненты), как показано на рис. 6.6.
6. На всех последующих экранах щелкайте на кнопке Next, пока не достигнете
экрана Confirm lnstallation Selections (Подтверждение выбранных настроек для
установки). Проверьте, все ли выбранные настройки корректны, и щелкните
на кнопке lnstall (Установить), чтобы начать процесс установки.

7. После завершения установки роли DNS Server щелкните на кнопке Close Закрыть) для закрытия окна мастера.
Установка роли подобным образом приводит к созданию изолированного серве
ра имен DNS, который взаимодействует только с корневыми серверами Интернета.
Он может поддерживать среду локальной вычислительной сети для преобразова
ния имен Интернета, но на этом и все. Система доменных имен использует другие серверы имен для преобразования имен по всей структуре DNS. По этой причине вы должны будете сконфигурировать сервер на взаимодействие с другими DNS серверами, которые существуют во внутренней сети. Хотя настройка DNS-cepвepa в автономной конфиrурации без присоединения к домену может иметь свои преимущества (вроде его развертывания в средах, где управление многочисленными статическими файлами ноsтs на серверах становится мучительным), действительная мощь системы Windows Server 201 2 R2 DNS проявляется при ее применении с Active Directory.

Интеграция с другими DNS-серверами

В разделе «Понятие роли DNS Server» упоминалось, что существуют разные ме
тоды для преобразования имен DNS, такие как переадресация, рекурсия, делегиро
вание и итерация. Эти методы относятся к интеграции с другими DNS-серверами.
Прежде чем начать, вспомните, что итерация по существу управляется клиентом.
Если DNS-cepвep не имеет ответа, клиент перейдет на другой DNS-cepвep. Сервер
или клиент можно настроить только на итерацию, но это не делается по умолчанию
и редко реализуется. Другие три приема — переадресация, рекурсия и делеrирова
ние — предусматривают взаимодействие запрашиваемого DNS-cepвepa с другими
D N S-серверами.
Рекурсия — это главный процесс, происходящий в Интернете. Запрашиваемый
DNS-cepвep начинает с самого верха и проходит вниз по ссылкам, получаемым от
каждого DNS-cepвepa, с которым он взаимодействует. На серверах Windows DNS
серверы верхнего уровня перечислены на вкладке Root Hiпts (Корневые подсказки)
диалогового окна свойств DNS-cepвepa (рис. 6.7). Это окно можно отобразить в
оснастке DNS Maпagemeпt (Управление DNS), щелкнув правой кнопкой мыши на
значке сервера и выбрав в контекстном меню пункт Properties (Свойства). По умол
чанию список Name servers (Серверы имен) на вкладке Root Hiпts заполнен «действующими» DNS-серверами из Интернета.
Roo t hnts resofve queries for zones that do not exist оп the 1оса1 DNS
serve- . lhey are ony used tf furwarders l>.EDU
О. ROOT-SERVERS . NЕТ.
;
; f o rmerly NS. NASA.GOV
Е. ROOT-SERVERS. NЕТ.
3600000
3600000
360000 0
36000 00
360000 0
36000 00
36000 00
36000 00
3600000
3600000
IN NS А. ROOT-SERVERS . NET.
д 198.41.0.4
NS В. ROOT -SERVERS. NET.
д 192 . 228. 79. 201
NS С . ROOT-SERVERS .NЕТ.
д 192. ЗЗ.4.12
NS О. ROOT-SERVERS .NET.
д 126.8.10.90
NS Е . ROOT -SERVERS.NEТ.
А 192.203.230.10
Рис. 6.8. Список корневых подсказок в файле cache . dns

В единственной среде домена Active Directory это можно оставить в том виде, как
есть. DNS-cepвepы могут использовать эти ссылки для распознавания пространств
имен, основанных на Интернете, таких как Sybex . сот, когда клиент их запраши
вает. В более крупных средах корневые подсказки на других серверах DNS можно
удалить и полагаться на поддержку одного сервера в преобразовании имен DNS из внешней среды. В сущности это мог бы быть кеширующий DNS-cepвep для внутренней структуры.
В то время как корневые подсказки управляют запросами, следующими вверх по
иерархической структуре DNS, делегирование управляет запросами, проходящими вниз. В рассматриваемом примере DNS-cepвepaм, которые управляют пространством имен . сот, делегируется контроль над зарегистрированными поддоменами вроде Sybex . сот. Делегирование представляет собой просто список этих серверов.
Таким образом, сервер имен . сот отправляет список серверов имен DNS-cepвepy,
ищущему пространство имен Sybex . сот.
В среде Windows делегирование можно увидеть в действии с множеством доменов Active Directory. При наличии домена Active Directory по имени Bigfirт . сот вы имеете связанное с ним пространство имен DNS под названием Bigfirт. сот. Вы могли бы создать домен Active Directory по имени Ecoast . Bigfirт. сот. Вместо
того чтобы хранить все пространства имен DNS на DNS-cepвepe Bigfirт. сот, вы
можете делегировать пространство имен DNS под названием Ecoast . Bigfirт. сот другому DNS-cepвepy.
На рис. 6.9 такое делегирование демонстрируется в консоли управления
DNS. В DNS-cepвepe по имени осо 1 поддерживается зона прямого просмот
ра Bigfirт. сот. Поддомен Ecoast, представленный значком с папкой серого
цвета с текстовым файлом поверх него, содержит только запись сервера имен для
ECl . Ecoast . Bigfirт. сот с его I Р-адресом.
Сервер пересылки — это еще один DNS-cepвep для обработки ответвленного за
проса. Когда серверу не удается преобразовать имя DNS, он может переадресовать
запрос другому DNS-cepвepy, а не проходить по корневым подсказкам.
Во внуrренней среде DNS серверы пересылки могут применяться дЛЯ распознава
ния других пространств имен. Например, DNS-cepвepy ECl . Ecoast . Bigfirm. com
необходимо распознавать серверы Bigfirm . com и другие пространстоа имен, по
этому на вкладке Forwarders (Серверы пересылки) окна его свойств указан сервер
пересылки (рис. 6.10).
На рис. 6. 10 обратите внимание на флажок Use root hints if по forwarders are
availaЫe (Использовать корневые подсказки, если нет доступных серверов пересылки). В более крупной среде его можно не отмечать, если необходимо централизовать DNS-запросы, основанные на Интернете. Кроме того, взгляните на текст, касающийся серверов условной пересылки.
Серверы условной пересылки имеют собственный узел в дереве областей внутри
левой панели окна DNS Manager (Диспетчер DNS). Для управления распознава
нием конкретного пространства имен сервер условной пересылки может направ
лять запросы определенному серверу. На рис. 6. 1 1 видно, что сервер условной
пересылки был настроен для пространства имен Otherdomain . local. В резуль
тате любые запросы к этому пространству имен будут передаваться DNS-cepвepy
OSOl . Otherdomain . local.
Серверы условной пересылки создаются путем щелчка правой кнопкой мыши
на папке Conditional Forwarder (Сервер условной пересылки) в консоли управления DNS и выбора в контекстном меню пункта New Conditional Forwarder (Новый сервер условной пересылки). Откроется диалоговое окно New Conditional Forwarder (Новыйсервер условной пересылки), которое предоставит вариант репликации настройки другим контроллерам домена в домене или лесе с использованием разделов каталога приложений Active Directory.
Переадресация также может применяться дЛЯ обработки запросов, основанных
на Интернете, вместо использования корневых подсказок.
Мы предпочитаем поступать так в небольших средах, обслуживаемых поставши
ком Интернет-услуг посредством кабеля или цифровой абонентской линии (Digital
Subscriber Liпe — DSL). Эти поставщики Интернет-услуг имеют собственные DNS
cepвepы, которые находятся в конфигурации маршрутизатора. Таким образом, ониуказаны как серверы пересылки во внутренних серверах DNS. Хотя корневые подсказки и могут работать в такой среде, мы считаем прием с переадресацией более надежным. Вдобавок он ограничивает коммуникации внутреннего DNS-cepвepa заданным внешним источником.
Интеграция с другими DNS-серверами может завершить конфигурирование
роли DNS. Один DNS-cepвep может получать запросы и затем отправлять их дру
гим DNS-cepвepaм. После того, как DNS-cepвep получит ответ, он может кеширо
вать информацию в течение определенного периода времени, который в Windows
Server 2012 R2 по умолчанию установлен равным одному часу. Такая конфигурация
называется сервером только для кеширования. Если сервер предназначен д.11я управления пространством имен, вы должны добавить зоны.

Реализация зон для управления пространствами имен

Зона — это база данных д.11я пространства имен. В И нтернете имеется DNS
cepвep, который управляет пространством имен Sybex . сот. Если вам необходим
1 Р-адрес для www . s уЬех . сот, то д.11я нахождения ответа этот DNS-cepвep будет
просматривать свою зону (базу данных). Таким образом, д.11 я управления пространс
твами имен на серверах DNS можно создать зоны.
На серверах Wiпdows DNS существуют зоны четырех типов:
• стандартная основная зона;
• стандартная дополнительная зона;
• зона, интегрированная с Active Directory;
• зона-заглушка.

Зона-заглушка не управляет пространством имен и
больше похожа на сервер условной пересылки. Все типы
зон обсуждаются в последующих разделах.
стандартная основная зона
Серверы имен были спроектированы для централиза
ции преобразования имен в сети. Первоначально DNS
cepвep отвечал на запросы, основываясь на своем текс
товом файле ноsтs. По существу это то, что в Microsoft
называют стандартной основной зоной. Стандартная ос
новная зона представляет собой текстовый файл, в ко
тором сервер поддерживает записи для заданного про
странства имен. Это то, что характеризует реализацию
Windows DNS как стандартную. Характеристика основная
относится к репликации.
Во времена Windows NT существовал один ведущий
контроллер домена, называемый главным контроллером
домена (primary domain controller — РОС), который уп
равлял всеми операциями записи в свою базу данных. Остальные операции управ
лялись резервными контроллерами домена (backup domain controller — BDC), которые представляли собой копии только для чтения. В терминах DNS основные зоны означают, что имеется только один хозяин, и им является данный сервер. Другие
DNS-cepвepы могут содержать лишь копии этой зоны, предназначенные только для
чтения; они являются дополнительными зонами.
Рис. б.12.
Создание НОВОЙ ЗОНЫ
Зона создается с помощью мастера новой зоны (New Zone Wizard), который
можно запустить, щелкнув правой кнопкой мыши на папке Forward Lookup Zones
(Зоны прямого просмотра) в диспетчере DNS и выбрав в контекстном меню пункт
New Zone (Новая зона), как показано на рис. 6.12.
Мастер новой зоны запросит перечисленную ниже информацию.
• Пространство имен или имя домена, такое как Primaryzone . local.
• Имя текстового файла, который по умолчанию имеет расширение . dns.
• Возможность динамического обновления DNS. Мы обсудим это в разделе
«Динамическое обновление DNS» далее в главе.
После создания зоны можно просмотреть содержимое текстового файла, кото
рый хранится в папке c : windowssystem32dns (рис. 6.13). Созданные для при
меров дополнительные записи CNAME и А находятся в конце файла.
Стандартная дополнительная зона
Стандартная дополнительная зона — это копия только для чтения стандартной
основной зоны или зоны, интегрированной с Active Directory. Репликация выполня
ется посредством процесса переноса зоны, который конфигурируется через свойс
тва зоны. На серверах Windows DNS стандартная настройка предусматривает раз
решение переносов зоны только на зарегистрированные серверы имен этой зоны,
что можно видеть на вкладке Zone Transfers (Переносы зоны), представленной на
рис. 6.14.
Чтобы разрешить репликацию на сервер имен ECl . Ecoast . Bigfirm . com, его
необходимо добавить в список Name servers (Серверы имен) на вкладке Name Servers
(Серверы имен), как показано на рис. 6.15.
Теперь можно запустить мастер New Zone Wizard для создания стандартной до
полнительной зоны на сервере ECl. Это потребует указания IР-адреса сервера-хозяина, у которого может запрашиваться перенос зоны. Он не обязательно должен
быть DNS-cepвepoм со стандартной основной зоной. Результатом будет успеш ный
перенос зоны на ECl (рис. 6.16).
Процесс переноса зоны не отличается особой сложностью. Сервер для основной
зоны отслеживает вносимые им изменения, назначая каждому из них серийный номер. Когда сервер для дополнительной зоны контактирует с сервером для основной
зоны, он проверяет этот серийный номер в записи Start of Authority (Начало зоны).
Если серийный номер на сервере для дополнительной зоны не совпадает, значит,
наступил момент для репликации изменений. Это просто текстовый способ заталкивания информации в базу данных. Ранние версии DNS поддерживали репликацию
AXFR (все переносы зоны), которая означала, что на сервер для дополнительной
зоны реплицировалась вся зона целиком. В результате по линии передавался намного больший объем трафика. В Windows DNS поддерживается репликация IXFR (инкрементные переносы зоны), при которой реплицируются только изменения. Кроме
того, в DNS поддерживается уведомление серверов для дополнительных зон, что сокращает время ожидания для запуска репликации.

Зона, интегрированная с Active Directory
Зона, интегрированная с Active Directory, является преобладаюшей реализацией
серверов Windows DNS. Присугствие в ее названии Active Directory говорит о многом.
• Во-первых, записи DNS хранятся в базе данных Active Directory, а не в тексто
вом файле.
• Во-вторых, зоны реплицируются всем другим контроллерам домена Active
Directory в домене, а не посредством процесса переноса зоны.
Поскольку в базе данных Active Directory применяется репликация с нескольки
ми хозяевами, изменения могуг вноситься в зону DNS на любом контроллере домена, и они будуг реплицироваться на другие контроллеры домена. Благодаря интеграции DNS с Active Directory, связка ролей DNS и контроллера домена становится
нормой. За дополнительными сведениями о процессе репликации обращайтесь в
главу 22.
Подобно стандартным зонам, зона, интегрированная с Active Directory, может
быть создана с помощью мастера New Zопе Wtzard. На экране Zone Туре (Тип зоны)мастера
На экране Active Directory Zone Replication Scope (Область действия репликации зоны Active Directory) мастера (рис. 6.1 на выбор предусмотрены четыре опции: науровне леса, на уровне домена, на уровне домена (совместимого с Windows 2000) и
хранение базы данных зоны в указанном специальном разделе каталога приложений
(последняя опция по умолчанию обычно недоступна, но в следующем абзаце мы
объясним, как сделать ее доступной). Первые две опции приводят к размешению
базы данных в автоматически созданном стандартном разделе каталога приложе
ний: один для леса и один для домена, членом которого является контроллер домена. Местоположением, совместимым с Windows 2000, является раздел домена базыданных Active Directory, поэтому база данных зоны будет реплицироваться только контроллерам этого домена.
Если вы хотите создать специальные разделы каталога приложений, такие как
отображаемый в последней опции на рис. 6. 18, то вам придется воспользоваться
либо утилитой DNSCmd, либо командлетом Add-DNSServerDirectoryParti tion
в PowerShell. Оба средства встроены в Windows Server 201 2 R2 и предоставляют
возможность управления указанными типами специальных разделов. В сеансе
PowerShell с разрешениями администратора введите показанную ниже команду, чтобы создать новый раздел каталога приложений для упомянутой ранее зоны, интегрированной с Active Directory. Имя раздела не обязательно должно совпадать с именем зоны; тем не менее, применение того же самого имени способствует лучшему пониманию конфигурации:
C : Usersadministrator . BIGFIRM>Add-DNSServerDirectoryPartition
-Name «adintegratedzone . local»
После того, как новый раздел создан, ему можно назначить зону, интегрирован
ную с Active Directory (см. рис. 6.18).
Затем также с помощью PowerShell можно сконфигурировать другие контролле
ры домена для поддержки зоны. Давайте предположим, что на сервере ECl, который является контроллером домена Ecoast . Bigfirm . com, необходимо добавить следующие две зоны Active Directory:
+ зону adintegratedzone . local, которая помещена в собственный раздел ка
талога приложений;
• зону обратного просмотра для подсети 192.168.0.0, которая помещена в общий
раздел леса.
Для начала добавьте сервер в список на вкладке Name Servers окна свойств жела
емых зон подобно тому, как было показано на рис. 6.15 ранее в главе.
Затем запустите следующий командлет для вывода доступных разделов на серве
ре ECl:
C : Usersadministrator . BIGFIRM>Get-DNSServerDirectoryPartition
В выводе можно заметить наличие четырех разделов каталога приложений.
Первый из них — это специальный раздел, созданный недавно, который сервер вовлек в совместное использование. Второй является разделом каталога приложенийдомена, который совместно используется всеми контроллерами домена, отличными от Windows 2000, внутри домена Bigfirm. com. Третий раздел предназначен для домена Ecoast . Bigfirm. сот. Четвертый раздел ориентирован на все контроллеры доменов в рамках леса доменов. Сервер ECl уже вовлечен в совместное использование этих двух разделов.
Использование зон-заглушек для интеграции с другими DNS-серверами
Зона-заглушка — это еще одно усовершенствование, впервые появившееся в
Windows Seiver 2003. В версии Windows Seiver 2012 R2 концепции и функциональность зоны-заглушки не изменились, и по суmеству она представляет собой дополнительный метод для интеграции с другими DNS-серверами. В зоне-заглушке перечислены только серверы имен для заданного пространства имен. Она не имеет никакого контроля над зоной, так что она указывает только на то, какой сервер мог бы поддерживать преобразование имен для пространства имен. Подобно серверам условной пересылки, зона-заглушка предоставляет ответвленное взаимодействие с авторитетным DNS-cepвepoм. Эти зоны также могут реплицироваться между конт
роллерами домена.
Мастер New Zone Wiz.ard настраивает зону-заглушку со следующими параметрами:
• тип зоны Stub (Зона-заглушка);
• необязательное хранение в Active Directory с заданным разделом каталога приложений;
• пространство имен зоны, такое как Арех. сот;
• DNS-cepвep, который поддерживает это пространство имен.
После создания зоны-заглушки можно просмотреть ее содержимое (рис. 6. 19).
В нем присутствует запись Start of Authority для пространства имен, запись Nam
Seiver (Сервер имен) для пространства имен и запись Host (Хост) для сервера имен.
Использование зон обратного просмотра для увеличения безопасности
Вы можете заметить, что созданные зоны находятся в папке Forward Lookup Zones
(Зоны прямого просмотра) внутри консоли управления DNS. При прямом просмот
ре клиент предоставляет полное имя домена (FQDN), а DNS-cepвep возвращает IР
адрес. При обратном просмотре делается противоположное: клиент предоставляет
IР-адрес, а DNS-cepвep возвращает имя FQDN.

Вас может интересовать, мя чего это может потребоваться? Основные причины
связаны с безопасностью. Представьте себе взломшика, который настроил вредонос
ную службу мя прослушивания DNS-запросов к именам FQDN, начинаюшимся с
www . , внутри сети. Когда эта служба получает запрос, она автоматически отправляет
клиенту поддельный ответ с 1 Р-адресом веб-сервера взлом шика, который загрузит
черви, вирусы, «троянские кони» еще до того, как пользователь узнает, что про
изошло. Если веб-браузер можно было бы сконфигурировать на выполнение обратного просмотра для предоставленного IР-адреса, то он мог бы сравнивать результат
с запрошенным именем и в случае несовпадения не подключаться к веб-серверу.
В качестве реального примера работы такого обратного просмотра при преобра
зовании имен можно привести службу SMTP в Windows. Эта служба позволяет вы
полнять обратный просмотр для подключений к серверу. Серверы SMTP предостав
ляют при взаимодействии свои доменные имена, а при подключении указывается адрес TCP/IP. Затем может быть выполнен обратный просмотр для проверки, соответствуют ли имена адресам, как должно быть.
Команда NsLookup иллюстрирует использование обратного просмотра. Как по
казано ниже, эта команда запушена в интерактивном режиме для сервера, который
не имеет записи указателя (PTR) в зоне обратного просмотра. Обратите внимание,
что стандартный сервер обозначен как UnKnown. В этом случае запросы DNS могут быть ненадежными.
C : UsersAdministrator . BFl>Nslookup
De fault Server : UnKnown
Address : 1 92 . 1 6 8 . 0 . 1 0
Если в зоне обратного просмотра создана запись PTR, то вывод команды
NsLookup выглядит гораздо лучше. Легко заметить, что в выводе присутствует имя
сервера:
C : UsersAdministrator . BFl>Nslookup
Default Server: BFl . bigfi rm . com
Address : 1 92 . 1 6 8 . 0 . 1 0
Для корректного конфигурирования зон обратного просмотра внутри сети не
обходимо понимать, как работает обратное преобразование. Адрес 1Pv4 представля
ется в десятичной точечной нотаuии с помощью четырех октетов — x.y.w.z. Адрес
1 Pv6 похож, но в нем применяются шестнадuатеричные числа, и их намного больше. В обоих случаях проuесс обратного преобразования один и тот же. DNS-cepвep,получающий запрос, изменяет порядок следования числе в IР-адресе. Таким образом, запрос имени FQDN мя IР-адреса x.y.w.z становится z.w.y.x, а в конuе добавляется . in-addr . arpa. Затем DNS-cepвep пытается преобразовать FQDN-имя z . w. у . х. in-addr . arpa подобно обычному имени FQDN. Преобразование начинается с домена верхнего уровня . arpa и проходит вниз к серверам имен in-addr . ,
при этом каждое десятичное значение становится поддоменом пространства имен справа от него. В небольших средах, которые включают только одну подсеть, эта подсеть может быть представлена единственной зоной. В рассматриваемом примере подсеть 192. 1 68.0.0 является одной зоной (рис. 6.20). При создании зоны обратного просмотра мастер New Zone Wuard запрашивает имя подсети.
В более крупных средах, имеющих несколько подсетей, потребуется создать зону
для октета с наибольшим приоритетом, а октеты с меньшими приоритетами должны быть представлены как поддомены или делегированные поддомены. Например,
если крупная организация использует схему частной I Р-адресации 10.0.0.0, то в ней можно создать зону обратного просмотра для доменного имени 1 О . in-addr . arpa.
Когда происходят динамические обновления, поддомены будут автоматичес
ки создаваться для следующего октета от l до 254, а записи PTR будут заполняться
подпапками структуры. В определенный момент поддомены можно делегировать
другому множеству DNS-cepвepoв, вроде контроJUiеров домена, находящихся внутри сайта, который содержит эти подсети. Затем записи PTR можно зарегистрировать в
соответствующей зоне, представляющей подсеть.
На рис. 6.21 видно, что на сервере BFl была создана зона 10 . in-addr . arpa.
Если нужно, чтобы подсети 10. 1 1.0.0 управлялись другим сервером, понадобится делегировать 1 1 поддоменов. Это было делегировано серверу ECl. Внутри него действительная подсеть 10. 1 1 .12.0 также представлена как делегированный поддомен.

На вкладJСе Advanced (Дополнительно) окна свойств DNS-cepвepa имеется несколь
ко отмеченных флажком, два из которых приведены ниже:
• ЕnаЫе round roЬin (Включить циклический перебор)
• ЕnаЫе netmask ordering ( Включить упорядочение сетевых масок)
Циклический перебор (round rоЬiп). Это прием балансировки сетевой нагрузки (network
load balancing — N LB) «для бедняков». Если вы зарегистрировали несколько записей
хостов с одним и тем же именем, но разными I Р-адресами, то DNS-cepвep будет от
вечать последовательно с отличающимся I Р-адресом для каждого запроса, начиная с самого меньшего IР-адреса. Хотя такой прием не распределяет клиентскую нагрузку равномерно или интеллектуально по доступным хостам, он все же предоставляет возможность некоторой балансировки между серверами.
Упорядочение сеrевых масок (пetmask ordering). Подобно циклическому перебору, при упорядочении сетевых масок используется множество записей хостов с одинаковым именем, но разными IР-адресами. Вместо выбора случайным образом выбирается запись, которая определена математически как более близкая. Это делается путем сравнения подсетей. Такой прием хорош при наличии географически разделенных хостов и клиенту необходимо взаимодействовать с хостом, находящимся в его сети. Таким
образом, когда примен яютс я географически разнесенные серверы, вы должны решить, какой метод лучше избрать. Упорядочение сетевых масок сохранит время отклика на минимальном уровне из-за более короткого маршрута. Циклический перебор более равномерно распределит нагрузку, если клиенты сконцентрированы в одном месте.
Однако эти процессы доступны в случае применения Wmdows Server 20 l 2 R2 с
Windows 7 или Windows 8. Стек TCP/IP для I Pv6 и I Pv4, «когда возможно», будет
выполнять процесс похожий на упорядочение сетевых масок, который называется стандартным выбором адресов. Это значит, что он получает I Р-адреса от DNS-cepвepa и самостоятельно решает, какой из них лучше использовать.
Подобно большинству конфигураций, это можно переопределить с помощью объекта групповой политики, указанного в следующем параметре реестра:
Hkey_Local_MachineSystemCurrentControlSet
ServicesTcpip ParametersOverrideDefaultAddressSelection
Значение 1 отключает стандартный выбор и разрешает произвольный выбор циклических серверов NLB.
Увидеть эффект от всего этого можно при использовании циклического перебора
географически ра:щеленных серверов. Например, среда с сайтом для восстановления после аварий может предлагать два сервера, которые выполняют одну и ту же службу,но расположены на разных сайтах. В таком случае для загрузки данных доступны два сервера FГР. DNS-cepвep сконфигурирован на предоставление двух I Р-адресов для одного имени ftp . Bigfirm. сот. Циклический перебор обеспечит последовательную обработку записей. Даже когда один из серверов FГР прекращает функционирование из-за аварийной ситуации, у клиентов по-прежнему сохранится подключаемость к ftp. Bigf irm. сот. (Время от времени будет выбираться IР-адрес нерабочегосервера, но после повторного подключения поток данных возобновится.)Тем не менее, если включено упорядочение сетевых масок или стандартный выбор адресов, то клиенты могут никогда не получить IР-адрес функционирующего сервера FГР. Выбор будет делать либо DNS-cepвep, либо клиент. Таким образом, этот сценарий наталкивает на применение проверенного временем правила: «тестировать,тестировать, тестировать». Проверяйте, какие серверы используются в нормальном сценарии, и что происходит в аварийной ситуации.

Типы записей

Теперь, когда базы данных настроены для извлечения информаuии клиента
ми, необходимо добавить в них записи. Как упоминалось ранее, Dynamic DNS
(DDNS) — это проuесс, который позволяет DNS-клиентам регистрировать свои
имена хостов в назначенном пространстве имен, таком как DHCP, и это приводит
к добавлению записей для компьютеров Windows внутри среды. Тем не менее, не
которые записи по-прежнему придется добавлять вручную, равно как и проверять
корректность записей, созданных динамически. Для зоны DNS доступно свыше
25 типов записей. В этом разделе мы рассмотрим наиболее распространенные типы записей в рамках реализации Windows DNS.
Записи хостов и указателей
Записи хостов (А) и указателей (PTR) наиболее распространены в зонах прямого
просмотра и зонах обратного просмотра, соответственно. В записи А указывается
имя хоста компьютера и возвращается !Р-адрес. В записи PTR указывается !Р-адрес
и возвращается имя FQDN. Эти записи может потребоваться создать дnя компьютеров, не имеющих доступного протокола обномения DDNS.
записи псевдонимов
Записи псевдонимов (CNAME) создаются для определения второго имени ком
пьютера. В записи CNAME указывается имя и возвращается имя FQDN, назначен
ное компьютеру. Эти записи полезны в случае замены сервера с опубликованным
именем, которое клиенты применяют для доступа к приложениям или службам. Безнеобходимости в переконфигурировании после замены клиенты по-прежнему будут иметь доступ через псевдоним.
записи обмена почтой
Записи обмена почтой (mail exchanger — МХ) предназначены для коммуникаций
по протоколу SMTP. Почтовые серверы запрашивают записи МХ пля взаимодейс
твия с получающим сервером SMTP в данном пространстве имен. Обычно записи
МХ настраиваются во внешней зоне DNS. Тем не менее, для специализированных
приложений они могут потребоваться и внутренне. Записи МХ нужно имя FQDN
сервера SMTP и значение приоритета.
Приоритет помогает определить, с какой записью МХ контактировать сначала,
а с какой впоследствии, если записей несколько. Чем меньше значение, тем выше
приоритет. Запомните это как «приоритет номер один».
Предположим, что у вас есть основной SМТР-сервер и SМТР-сервер типа смарт
хост (smart host), предназначенный для поддержки получения электронной почты, когда основной сервер недоступен. Вам необходимо создать записи МХ для обоих серверов. Основной SМТР-сервер должен иметь меньшее значение приоритета, чем смарт-хост, например 10 и 20, соответственно. Когда основной SМТР-сервер недоступен, взаимодействие производится со смарт-хостом.
Записи служб
Записи служб (SRV) являются «знатным шаманом» для реализаuий Windows
DNS. Без записей SRV рабочие станции и серверы не смогли бы находить контрол
леры доменов.

Сами по себе записи SRV имеют дело только с пятью значениями.
• Имя службы. Стандартное значение, обычно предваренное символом подчер
кивания, такое как _gc или _ ladp. Оно является эквивалентом имени хоста и
будет присоединено к имени FQDN службы.
• Имя FQDN сервера. Сервер, который предоставляет службу.
• Порт. Порт ТСР или UDP, на котором доступна служба. Протокол обозначает
ся своим зарегистрированным именем, например, _ ТСР.
• Приоритет. Работает точно так же, как в записях МХ — имеет «приоритет но
мер один».
• Вес. Используется для разрешения конфликтов с приоритетами. Оставьте его
равным О, если вас это не заботит.
Вы обнаружите изобилие записей SRV в зоне Windows DNS, которая поддерживает
Active Directory. Они находятся в папках поддоменов, поскольку именам служб назначаются разные имена FQDN. Запрашиваемая служба описывается с помощью имени
FQDN наподобие _gс . tcp .Ьigfirrn. corn. Записи SRУ можно видеть на рис.
Записи начала зон
Запись начала зоны (Start of Authority — SOA) в единственном экземпляре при
сутствует в каждой зоне. Она определяет информацию о том, какой DNS-cepвep уп
равляет этой зоной, а также параметры, касающиеся того, каким образом трактовать
распознанные записи. Запись SOA содержит несколько значений, которые не должны изменяться при редактировании записи. Редактирование производится на вкладке Start of Authority (SOA) (Запись начала зоны (SOA)) в окне свойств зоны (рис. 6.23).
Ниже описаны поля, находящиеся на вкладке Start of Authority (SOA).
• Serial Number (Серийный номер). Номер ревизии файла зоны. На самом деле
он имеет значение для стандартных основных зон, т.к. репликация Active
Directory поддерживает собственный серийный номер. Дополнительные зоны
могут сравнивать с ним свои номера, чтобы выяснять, актуальна ли информа
ция в них. Если информация не актуальна, необходим перенос зоны.

• Primary Server (Основной сервер). Сервер, на котором зона была изначально
настроена. Если вы хотите изменить способ обновления зон в среде посредс
твом репликации, можете переключать основной сервер на дополнительный
сервер и наоборот.
• ResponsiЫe Person (Ответственное лицо). Предположительно это должен быть
адрес электронной почты лица, администрирующего зону. Обратите внимание,
что символ @ заменяется точкой ( . ). Если хотите кого-то по-настоящему свес
ти с ума, можете указать здесь его электронный адрес.
• Refresh lnterval (Интервал обновления). Период времени, в течение которого
дополнительный сервер может ожидать до того, как начнет попытки прове
рить наличие изменений на основном сервере. В этот момент он сравнивает
серийный номер из записи SOA со своим номером. По умолчанию интервал
обновления составляет 1 5 минут. Внутри самой записи это значение указыва
ется в секундах.
• Retry lnterval (Интервал повтора). Период времени, в течение которого допол
нительный сервер ожидает до того, как повторить попытку после отказавшего
переноса зоны. По умолчанию интервал повтора составляет 10 минут и также
внутри самой записи указывается в секундах.
• Expires After (Истекает после). Период времени, в течение которого дополни
тельный сервер может продолжать отвечать на запросы в этой зоне после того,
как перенос зоны был выполнен. По умолчанию составляет один день. Внутри
самой записи это значение также указывается в секундах и равно 86 400.
• Minimum (Detault) TTL (Минимальное (стандартное) время ТТL). Период време
ни, в течение которого запись должна находиться в кеше или, другими слова
ми, значение времени существования (Time То Live — ТТL). По умолчанию
составляет один час, или 3 600 секунд.

записи серверов имен
Записи серверов имен (NS) перечисляют серверы, которые могут отвечать на за
просы для этой зоны. В зоне должна присутствовать, по меньшей мере, одна такаязапись. Подобно записи SOA, запись NS модифицируется на вкладке Name Servers(Серверы имен) окна свойств зоны, которая была показана ранее на рис. 6.15.Единственным обязательным значением в записи NS является имя FQDN сервера.В нижней части вкладке Name Servers вы заметите короткое примечание, указывающее на то, что 1 Р-адрес представляет собой извлеченное значение.

Управление клиентами DNS и преобразованием имен

Вы можете прийти к выводу, что каждый компьютер является клиентом DNS.
Служба DNS — это жизненно важный компонент сети, даже если Active Directory не входит в ее состав. Вдобавок он представляет собой единственный метод для перехода на ваши избранные веб-сайты в И нтернете, такие как www . Sybex . сот.
В операционных системах Windows есть две области, касающиеся клиентов DNS:
преобразование имен хостов и регистрация имен хостов и I Р-адресов через динами
ческие обновления DNS.
Преобразование имен хостов
Процесс преобразования имен на компьютере Windows делится на две части.
Данный процесс настолько важен, что мы будет называть его «жизненным циклом».
Одной частью, которая близка к исчезновению, является NetBIOS, в друтой — DNS.
(Вы могли бы назвать ее процессом имени хоста, но большинство администраторов
называют его DNS.) Этот цикл состоит из набора шагов, которые компьютер дол
жен предпринять для преобразования заданного имени (рис. 6.24).
Преобразование имен NetBios,__-+- —
Ретрансляция
Поиск в DNS
Поиск вWINS
Файл HOSTS
Файл LMHOSТS
Преобразование (имен хостов) DNS

Процесс NetBIOS предусматривает выполнение следующих шагов.
1 . Ретрансляция имени в сети и ожидание, ответит ли кто.
2. Поиск имени в WNS.
3. Поиск имени в файле LMHOSTS. Это еще один текстовый файл, аналогич
ный файлу ноsтs, который находится в том же самом месте: с : windows
system32 drivers etc. Вместо имен хостов в нем перечислены имена
NetBIOS.
Порядок следования первых двух шагов можно изменять, особенно через сервер
DHCP. Шаг с ретрансляuией или шаг с поиском в WINS может быть опущен. По
умолчанию в Windows Server 2012 R2 сначала производится поиск имени посред
ством WINS, а затем с помощью ретрансляции. Однако поиск в файле LMHOSTS
всегда выполняется последним.
Список шагов для процесса DNS короче.
1. Поиск имени в файле HOSTS.
2. Поиск имени в DNS.
Порядок следования шагов в процессе DNS настройке не поддается, но можно
изменить поведение просмотра DNS. С тем, что поиск имени сначала производится
в файле ноsтs, связаны как положительные, так и отрицательные моменты. Если
получить доступ к DNS-cepвepy невозможно или требуется переадресовать преобра
зование имени в другое место, то редактирование файла ноsтs дает замечательные
результаты. Если же файл ноsтs содержит устаревшие или вредоносные записи, то
устранение неполадок DNS может оказаться затруднительным.
Процесс преобразования имен циркулирует по обеим частям до тех пор, пока не
будет получен IР-адрес. Кроме того, имеется выбор с чего начинать — NetBIOS или
DNS. В основном это зависит от приложения. Старые унаследованные приложения
Windows рассматривают имя как относящееся к NetBIOS. Приложения, основанные
на TCP/IP, считают его именем хоста. Это влияет на способ преобразования имен и является частью операционных систем Windows.
Примерами могут служить команды net view и ping.
Комама net view существует со времен LAN Manager, когда все полагалось uе
ликом на NetBIOS. Если вы попытаетесь подключиться к серверу с применением
указанной команды, то увидите, что имя сервера заносится в кеш имен NetBIOS.
Содержимое этого кеша можно отобразить с помощью команды nЬtstat — с . Для
очистки кеша предназначена команда nbtstat -R.
rem Просмотр кеша имен NetBios
С: Users Adrnini strator . BFl >nhtstat -с
Local Area Connection :
Node IpAddress : [ 1 92 . 1 68 . 0 . 1 0 ] Scope Id: [ ]
No names in cache
rem Доступ к общим ресурсам на сервере Ьfscl
С: UsersAdrninistra�or . BFl>net view Ьfscl
Shared resources at \bfscl
Share name Туре Used as Comment
NETLOGON Disk Logon server share
SALES Disk
SYSVOL Disk Logon server share
Users Disk
The command completed success fully .
rem Повторный просмос>р кеша имен NetBios
С : UsersAdminis trator. BFl>nЬtstat -с
Local Area Connection :
Node IpAddress : ( 1 92 . 1 68 . 0 . 10 ] Scope I d : [ ]
NetBIOS Remote Cache Name ТаЫе
Name Туре
Host Address
BFSCl UNIQUE 1 92 . 1 68 . 0 . 1 1
ГЛАВА 6
Life [ sec]
6 0 0
При пинговании сервера используется проuесс DNS, т.к. команда ping являет
ся утилитой ТСР /1 Р. Вы можете убедиться, что эта утилита распознает сервер че
рез DNS, отобразив содержимое кеша DNS с применением команды ipconfig
/di splaydns. Кеш DNS очищается с помощью команды ipconfig / flushdns.
rem Очистка кеша DNS
С : Users Administrator . BFl>ipconfiq /flushdns
Windows I P Configuration
Success fully flushed the DNS Resolver Cache .
С : Users Administrator. BFl>pin9 BFSCl
Pinging BFSCl . bigfirm . com [ 1 92 . 1 68 . 0 . 1 1 ] with 32 bytes o f data :
Reply from 1 92 . 1 68 . 0 . 1 1 : bytes=32 time Reply from 192 . 1 68 . 0 . 1 1 : bytes=32 time Reply from 1 92 . 1 68 . 0 . 1 1 : bytes=32 time< lms TTL=128
Reply from 1 92 . 1 68 . 0 . 1 1 : bytes=32 timeipconfiq /displaydns
Nindows I P Con figuration
BFSCl
Record Name .
Record Туре .
Time То Live
Data Length .
Section . . .
А ( Host ) Record .
BFSCl . bigfirm . com
1
1 1 8 5
4
Answer
1 92 . 1 68 . 0 . 1 1
Такие сведения помогают решить, каким образом поддерживать проuесс преоб
разования имен DNS для клиентов и устранить либо поддерживать (при необходи
мости) имена NetBIOS. Проuесс NetBJOS потребляет излишние uиклы ЦП. В слу
чае корректной конфигурации сервера и клиентов DNS поддержку преобразования
имен NetBIOS можно отключить или, по крайней мере, свести к минимуму.
Конфигурирование клиентов
Конфигураuии DNS и NetBIOS можно просмотреть в окне свойств протокола IP
для сетевого подключения. Конфигурация NetBIOS находится на вкладке WINS. На
рис. 6.25 показана вкладка WINS со стандартными настройками.

По умолчанию включен поиск в файле LMHOSTS и выбрано использование на
строек NetBTOS из сервера DHCP. По умолчанию файл LMHOSTS пуст. Было бы не
плохо отключить поиск в этом файле, поскольку вредоносное ПО могло в прошлом
занести в него данные.
Настройки NetBIOS получаются от сервера DHCP. Области видимости сервера
DHCP имеют опцию под названием NBT Node Туре (046) (Тип узла NBT (046)). Эта
настройка предписывает первые два шага проuесса NetBIOS в жизненном uикле.
Четыре опuии задаются десятичным значением:
• только ретрансляция: «Ь-узел», 1
• только обращение к WINS: «р-узел», 2
• сначала ретрансляция, а затем обращение к WINS: «m-узел», 4
• обращение к WINS, а затем ретрансляция: «h-узел», 8
Н-узел лучше всего подходит для сети, полагающейся на NetВIOS, т.к. он сокра
щает объем обмена в среде, поддерживающей WINS. При отсутствии доступных сер
веров WINS компьютер может, по крайней мере, получить какой-то ответ в подсети,
например, дома или в рабочей группе. Если сервер DHCP не сконфигурирован с этим значением, применяется стандартная конфигурация, установленная в ОС. В Windows Server 2012 R2 по умолчанию используется h-узел, т.е. rибридный (hybrid) режим.
Дrtя сред Active Directory лучше отключать NetBIOS, поскольку это сокращает объ
ем дополнительного обмена и количество процессов. Кроме тоrо, это помогает снизить
угрозы безопасности со стороны ботов, которые ищут в сетях компьютеры с целью
атаки с применением данной системы имен. Однако прежде чем отключать NetBIOS,
удостоверьтесь в отсутствии слабых мест в системе преобразования имен DNS.
Конфигурация клиента DNS находится на вкладке DNS окна свойств сети, по
казанной на рис. 6.26. Вполне очевидно, что обязательным является IР-адрес DNS cepвepa. Подключение должно осуществляться к ближайшему серверу, как правило,
на контроллере домена внутри локального сайта. Рекомендуется указать также дополнительный DNS-cepвep.
Advanced TCP/IP Settings

Средняя часть вкладки DNS имеет отношение к неполным именам. Это имя хос
та без его «второго имени», суффикса DNS (такого как BFSCl, используемого ра
нее в примере команды ping). DNS-cepвepy необходимо имя FQDN, поэтому пе
ред отправкой запроса клиент DNS добавляет суффиксы DNS, т.е. «второе имя».
Основной суффикс DNS отображается на странице System (Система) панели уп
равления, в области Computer Name (Имя компьютера). Он управляется автомати
чески ОС, когда компьютер присоединяется к домену, поэтому заботиться об этом
суффиксе не придется. Дополнительные суффиксы могут понадобиться в крупных
средах, но для сред с одним доменом стандартных настроек вполне достаточно.
Добавлять суффикс DNS подключения нужно только в редких случаях.
Все это становится спорным в случае регулярного применения имен FQDN.
Используйте имена FQDN серверов при конфигурировании приложений, папок
или переадресации папок, равно как при написании сценариев, которые подклю
чают сетевые диски. Уловили смысл? Вдобавок применение имен FQDN обходит
процесс NetBIOS. Приложения могут определить разницу между именами NetBIOS
и FQDN и прибегнуть к DNS, когда они распознают FQDN.

динамическое обновление DNS
Чтобы сделать процесс преобразования имен DNS надежным, понадобится пе
речислить все компьютеры в зонах DNS. В прошлом система DNS требовала от
системных администраторов работы в полную смену, т.к. нужно было вводить постоянно растущее количество записей для их сети. Для сокращения объема работы системных администраторов в Microsoft при создании ОС Windows NT нашли динамическое решение через WINS и затем перешли на DNS, когда стал доступным протокол обновлений Dynamic DNS (DDNS). Сам процесс довольно прост.
1. Клиент запрашивает запись SOA мя пространства имен с основным суффик
сом DNS. Это сообщит, может ли сервер принимать DDNS. То же самое дела
ется для зоны обратного просмотра, с которой связан 1 Р-адрес сервера.
2. Клиент отправляет запрос DDNS этому серверу.
В записях Start of Authority стандартных зон указан основной сервер. В зонах,
интегрированных с Active Directory, контроллер домена, получающий запрос, моди
фицирует запись SOA с таким именем. Поскольку он может изменять содержимое
базы данных Active Directory, нет нужды выискивать контроллер домена, находя
шийся где-то в другом месте. Если процесс обновления терпит неудачу, производится поиск других серверов имен для выполнения обновлений.
На вкладке DNS с протоколом обновлений DDNS связаны два флажка в самом
низу (см. рис. 6.26). Имеется возможность зарегистрировать имя с основным суффиксом DNS или с суффиксом подключения. Второй флажок по умолчанию не отмечен.
Странно то, что служба клиента DNS не выполняет обновления DDNS. Это де
лает служба клиента DHCP. Это напоминает нам богатый событиями день, когда
один из нас отключил службу клиента DHCP на контроллере домена. Он наивно
полагал, что эта служба не нужна, т.к. имеется статический IР-адрес. Как уже упоминалось, �процесс DDNS используется контроллерами домена с целью предоставления записей SRV для Active Directory. В конечном итоге клиенты не смогли найти контроллер домена, т.к. для него не было никаких записей SRY. К счастью, все это происходило в испытательной среде.
Существуют еше два места, где производится управление процессом DDNS: зона
для пространства имен и сервер DHCP.
Зона DNS может быть включена для обновлений DDNS в мастере New Zone
Wizard или же путем изменения свойств зоны. На рис. 6.27 показаны опции для обновлений DDNS — только безопасные, безопасные и небезопасные, а также пол
ное отключение обновлений. Безопасные динамические обновления означают, что до их выполнения клиент DNS проходит аутентификацию на контроллере домена. Небезопасные динамические обновления означают, что они принимаются без аутентификации. Учитывая название, вы легко можете предположить, что злоумышленники способны воспользоваться этой опцией. В случае отключения никакие обнов
ления DDNS поступать не будут.
Сервер DHCP также может участвовать в процессе DDNS. В самых ранних вер
сиях Windows Server было много клиентов Windows, которые не обладали возмож
ностями DDNS. Для решения этой проблемы сервер DHCP идентифицирует такие
ОС и выполняет мя них обновления. Кроме того, сервер DHCP может выполнять
обновления по запросу. На рис. 6.28 приведена вкладка DNS окна свойств 1 Pv4 для сервера DHCP.
Здесь показаны стандартные настройки, которые редко изменяются. В сущности,
сервер DHCP не выполняет никаких обновлений, поскольку клиенты делают это
самостоятельно. Сервер DHCP производит очистку, когда истекает срок аренды.
Защита имен, включаемая за счет отметки флажка в окне, открывающемся по щелчку на кнопке Configure (Конфигурировать) в области Name Protectioп (Защита имен),предотврашает обновление сервером DHCP существуюшей записи DNS.

Система DNS в Active Directorv

В Microsoft настолько тесно интегрировали DNS и Active Directory, что обсуж
дать их по отдельности довольно трудно. Во время создания среды Active Directory с Windows Server 2012 R2 проuесс установки Active Directory автоматически конфигурирует DNS при добавлении роли. Это освобождает спеuиалистов по 1Т от ручной настройки DNS.
В последующих разделах мы раскроем способ, которым Active Directory конфиrу
рирует систему DNS и применяет ее для поддержки клиентов. За дополнительными
сведениями о терминах и конuепuиях Active Directory обращайтесь в главу 7.

Автоматическое конфигурирование DNS

ОС Windows Server 2012 R2 предлагает два способа установки службы DNS: до
бавление роли DNS самой по себе (как было показано ранее для автономной кон
фигурации, не присоединенной к домену) или добавление роли Active Directory
Domain Services (Службы домена Active Directory). В случае выбора второго спо
соба вы должны запустить мастер установки служб домена Active Directory (Active
Diгectory Domain Services lnstalation Wizard), который проведет ряд настроек для
роли Active Directory Domain Services, включая автоматическое конфигурирование
и интеграцию с ролью DNS. В главе 7 процесс установки Active Directory будет рас
смотрен во всех деталях, а здесь мы лишь посмотрим, что произоЙдет с ролью DNS.
Первым делом вы должны понять предварительные условия, которые должны
быть удовлетворены для проведения установки Active Directory. Будущему конт
роллеру домена необходима возможность подключения к существующей структуре
Active Directory DNS. В противном случае нельзя будет подключиться к контрол
лерам домена и получить нужную информацию. Таким образом, в настройках IР
адресов должен быть указан DNS-cepвep внутри среды Active Directory, желательно
DNS-cepвep корня леса или DNS-cepвep в том же самом домене, к которому пла
нируется присоединение. Единственным исключением является ситуация, когда создается самый первый контроJVIер домена в среде Active Directory. В этот момент нет
никакой структуры Active Directory DNS, на которую можно было бы указывать.
Во время выполнения мастера Active Directory Domain Services конфигурируется
новый контроллер домена. В зависимости от опций, выбранных в мастере, может
быть создан новый контроллер домена. В любом случае служба DNS и соответству
ющие настройки конфигурируются автоматически. В среду вносятся описанные далее изменения.
Создание разделов каталога приложений
Разделы каталога приложений — это граниuы внутри базы дан ных Active
Directory, которые создаются для совместного использования зон DNS разными до
менами при создании нового домена или леса.
Раздел Doma inDNSZones . doma in . name создается для контроллеров домена
внутри домена. Раздел ForestDNSZones . domain . name создается для совместного
использования контроллерами домена в рамках леса Active Directory.
Если вы снова взглянете на рис. 6.9, то заметите, что поддомен msdcs .
Ьigfirm . com делегирован подобно Ecoast. Он делегирован на тот же самый конт
роллер домена, в рассматриваемом случае это DCOl . Bigfirm. com.
Зона _msdcs . Bigfirm . com создается в разделе ForestDNSZone . Bigfirm . com
каталога приложений. Это позволяет данной порции пространства имен реплицироваться на все домены внутри леса.
После создания дополнительных контроллеров доменов они автоматически по
являются в этих разделах каталога приложений.
Добавление сервера пересылки
Сервер пересылки можно добавить, просмотреть и сконфигурировать на вкладке
Forwarders (Серверы пересылки) окна свойств DNS-cepвepa. Обычно это будет IР
адрес исходного DNS-cepвepa, которым пользовался данный сервер.
Изменение /Р -адреса
Новый контроллер домена, созданный мастером Active Directory Domain Services
Wizard, также является новым DNS-cepвepoм. Адрес основного DNS-cepвepa кон
фигурируется на I Р-адреса обратной связи ::1 (для 1Pv6) и 127.0.0. 1 (для 1Pv4).
делегирование поддомена
Дочерний домен имеет имя, являющееся поддоменом внутри существующе
го пространства имен домена. Например, Ecoast . Bigfirrn . corn — это поддомен
в пространстве имен Bigfirrn . corn. В результате работы мастера Active Directory
Domain Services Wizard пространство имен нового домена будет поддерживаться в
новом контроллере домена в виде делегированного поддомена.
В родительском домене поддомен вроде Ecoast . Bigfirrn. corn делегируется но
вому контроллеру домена. Делегирование свяжет родительский и дочерний домены дпя преобразования имен. Это иллюстрировалось ранее на рис. 6.9.
дополнительные рекомендации по конфигурированию
После создания контроллера домена мы рекомендуем внести в настройки DNS
перечисленные ниже изменения.
1 . В свойствах ТСР /1 Pv4 сетевого адаптера измените основной DNS-cepвep на 1 Р
адрес основного сетевого подключения. Например, если IР-адресом сервера яв
ляется 192.168.0. l, его понадобится указать в качестве основного DNS-cepвepa.
При поиске и устранении неполадок в DNS с помощью утилиты NsLookup ад
рес обратной связи ( 1 27.0.0. 1) указывается как «неавторитетный». Мы нахо
дим результаты применения адреса обратной связи несколько ненадежными,
поэтому лучше придерживаться основного I Р-адреса.
2. Создайте зоны обратного просмотра в разделе ForestDNSZones . dornain . name каталога приложений.Зону обратного просмотра для подсетей может потребоваться совместно использовать в контроллерах различных доменов.
3. Создайте зону-заглушку для новых деревьев доменов на корневом DNS
cepвepe.
Дерево домена имеет имя, отличающееся от имени корневого DNS-cepвepa.
Поскольку запись об исходном DNS-cepвepe указана как сервер пересылки,
подобно поднятиям других контроллеров домена, этот DNS-cepвep может
взаимодействовать с остальной структурой Active Directory DNS. Тем не ме
нее, для остальной структуры Active Directory DNS никакого автоматического
конфигурирования для преобразования имен в новом пространстве имен не
предусмотрено. Например, нам придется настроить сервер условной пересыл
ки или зону-заглушку, чтобы нацелить DNS-cepвepы на новый контроллер до
мена для Арех. сот. На рис. 6. 19 демонстрируется применение зоны-заглушки
для содействия преобразования имен FQDN домена Арех . com.

Записи SRV и клиенты

Глядя на зону DNS нового домена, вы заметите наличие в ней множества новых папок или поддоменов. Открывая эти папки, вы найдете множество записей расположения служб, как было показано ранее на рис. 6.22. Как уже упоминалось, записи SRV и динамические обновления DNS необходимы для обеспечения работы Active Directory.
Они представляют собой результат совместного функuионирования двух технологий.
Служба netlogon выполняет запросы DDNS для создания записей SRV внутри
пространства имен Active Directory DNS. Единственная причина заключается в гарантировании того, что компьютеры смогут найти контроллеры домена.
Внутри проuессов ОС Windows определенные службы находятся с исполhЗовани
ем DNS. На рис. 6.22 присутствовало несколько служб:
• _gc (global catalog — глобальный каталог) — служба LDAP для поиска данных
в глобальном каталоге;
• kerberos — проuесс аутентификаuии;
• kpassword — еще одна часть процесса аутентификации;
• ldap — служба LDAP для поиска данных в домене.
Каждая из перечисленных служб выполняется контроллерами домена внут
ри домена или леса. На рис. 6.22 было видно, что все эти роли выполнялись на
DCOl . Bigfirm. сот и прослушивался порт ТСР.
Таким образом, когда компьютеру Windows требуется какая-то служба контроллера домена, например, LDAP, он запросит запись SRV для ldap . tcp . Bigf i rrn . сот.
После этого он получит все, что необходимо мя взаимодействия с IР-адресом и
портом.
Если компьютеру Windows нужно найти контроллер домена внутри собственного
сайта, он может искать его в поддомене sites . Bigfirm . com. В этом поддомене будут отображаться все созданные сайты в консоли Active Diгectory Sites and Services(Сайты и службы Active Directory).
Вероятность того, что администраторы могли бы поддерживать все это множес
тво записей DNS вручную, довольно низка. Для одного контроллера домена можно
ожидать регистрации, по меньшей мере, 16-20 разных записей SRV. Изучение их
всех — задача, безусловно, не из простых. Именно здесь в игру вступают инструменты, подобные DcDiag. Инструкции по работе с этими утилитами приведены в разделе «Использование NsLookup и DcDiag» далее в главе.

Дополнительные компоненты Windows Server 2012 R2

К этому моменту мы обсудили существенные компоненты и способы обраще
ния с ними, что уже позволяет вам достаточно квалифицированно управлять средой Windows Server 2012 R2 DNS. В настоящем разделе будут рассматриваться дополнительные компоненты DNS в Windows Server 2012 R2, которые развертываются не так
часто, как основные компоненты, но о которых, тем не менее, полезно знать.
rлобальный список блокировки запросов
Существует несколько распространенных записей хостов, которые могут быть за
регистрированы в DNS другими службами. Одной из таких служб является протокол
автоматического обнаружения веб-прокси (\еЬ Proxy Automatic Discovery Protocol —
WPAD). Он помогает веб-браузерам автоматически загружать конфигураuии прок
си из сервера. Так как эта запись не относится к конкретному компьютеру, любой
компьютер, включая потенциально скомпрометированный злоумышленниками, может попытаться зарегистрировать свое имя. Другой распространенной записью хоста является протокол автоматической внутрисайтовой адресаuии туннелей (lntra-Site Automatic Tunneliпg Addressing Protocol — ISATAP). Как объяснялось в главе 4, протокол ISATAP предназначен для выполнения маршрутизации из сети 1Pv4 в сеть 1Pv6.
В глобальном списке блокировки запросов (global query Ыосk list) указаны имена, для которых регистраuия DDNS заблокирована. Таким образом, попытки компьютера злоумышленника зарегистрировать имена WPAD или ISATAP отклоняются.
Показанные ниже команды иллюстрируют способы администрирования это
го списка. Для просмотра списка служит командлет Get — DNSSe rverGl oba l
QueryBlocklist. Обратите внимание, что по умолчанию в списке находятся wpad
и isatap.
C : UsersAdministrator . BFl>Get-DNSServerGlobalQueryBlocklist
ЕnаЫе : True
List : { wpad, isatap }
Чтобы добавить в этот список имя вроде www, можно воспользоваться командле
том Set-DNSServerGlobalQueryBlocklist. По умолчанию компонент глобально
го списка блокировки запросов включен. Он отключается и повторно включается с применением опции -ЕnаЫе со значением $True или $False.
Преобразование глобальных имен и одиночных имен
Даже с учетом того, что использование WINS идет на убыль, возникает пот
ребность в поддержке для некоторых приложений процесса преобразования имен
NetBIOS. Компонент GlobalNames (глобальные имена) — это специальная зона, созданная для преобразования имен NetBIOS (15 символов безо всяких точек). Клиент
DNS осуществляет запрос в зону GlobaName, когда поиски с основным и дополни
тельным суффиксом DNS завершились неудачей.
Конфигурирование компонента GlobalNames выполняется несложно.
1. Создайте новую зону по имени GlobalNames.
Рекомендуется выбрать тип зоны, интегрированной с Active Directory, чтобы
обеспечить репликацию в другие контроллеры домена.
2. Включите поддержку зоны Gl oba lNames с помощью командлета Set
DNSServerGlobalNameZone:
C : UsersAdmiпistrator . BFl>Set-DNSServerGlobalNameZoпe -ЕпаЫе $True
3. Проведите репликацию зоны в другие контроллеры домена.
Не забудьте добавить эти контроллеры домена в список серверов имен для зоны.
4. Добавьте в зону записи CNAME для переадресации на определенные хосты.
В данном примере www переадресуется на hostrecord . Pr imaryZone . local
(рис. 6.29).
5. Добавьте запись местоположения службы, если необходимо, чтобы эту зону
запрашивали другие леса Active Directory.
DNS И ПРЕОБРАЗОВАНИЕ ИМЕН В WINDOWS 5ERVER 201 2 R2
DNS Manager
———-�.— — ——
� � С a:ched Lookups
� ..::J Forwгrd loolcup Zont’S
1> ,Vf _msda.Bigfirm.com
1> :Р 1dint�nite:hone.loc1J
1> …; Bigfirm.com
.:,c_Gl_o_balNomt:’:
� Prim1ryZone.lcк.al
1> _. R�erse lookup Zon�
1> _.; Trust:Po1nts
1>
Cond» rtionlll Fo�rders
1> IDJ G l o bal log:.
! Name Туре Dat.• Тimm:.Jmp
{] (same 1Js p1tr.» SЬrt of Authonty(SOA) 111 dc01.bigfirm.com» hostm.itst.» static
� (same IS rur». N t!t m e Smrer (NS) dc01.Ьigfirm.com. stnic
{ijwww AJi1s (СNАМЕ) hostrecord.Prim1ryZone.loc1’i
< f . » Рис. 6.29. Зона GlobalNames 277 Протестировать преобразование глобальных имен можно посредством уrилиты NsLookup: C: UsersAdrninistrator . DCl>Nslookup
Default Server : DCOl .Ыgfirm. com
Address : 1 92 . 1 68 . 0 . 1
> www
Server :
Address :
Name :
Address :
Aliases :
DCOl .Ыgfirm. com
1 92 . 1 68 . 0 . 1
hostrecord.primaryzone . local
1 92 . 1 68 . 0 . 2 1
www . Ьigfirm. com
Как обсуждалось ранее, в большинстве сред, полагающихся на серверы Windows,
потребность в преобразовании одиночных имен (NetBIOS) сведена к минимуму.
Она также была минимизирована за счет подходящего развертывания приложений с
применением имен FQDN и привлечения DNS.
Фоновая загрузка зон
Некоторые старые среды имеют настолько большие зоны DNS, что перезапуск
службы DNS контроллерами доменов занимает более часа. Для решения этой про
блемы предназначено средство фоновой загрузки зон. Чтобы такая проблема воз
никла, зона DNS должна содержать огромное количество записей.
Во время запуска службы DNS она начинает реагировать на запросы к зонам,
которые уже загрузились. Запросы к пока еще не загруженным зонам будуr отсы
латься другим DNS-cepвepaм.
DNSSEC
Подобно НТТР, система DNS является нешифрованной и неауrентифицируе
мой. Как упоминалось при рассмотрении зон обратного просмотра, злоумышленни
ки мoryr подделывать ответы DNS. Чтобы противостоять этому, были разработаны
стандарты DNSSEC (DNS Security Extensions — расширения безопасности DNS),
которые позволяют DNS-cepвepy добавлять цифровую подпись к записям ресурсов.
ОС Windows Server 2012 R2 обеспечивает поддержку дополнительных зон как зон
DNSSEC. Она реагирует только на запросы записей из зоны с цифровой подписью.
ОС также будет предостамять необходимые записи ресурсов для аутентификации
подписи.
Такими записями ямяются КЕУ, SIG и NXT Запись КЕУ — это открытый ключ
подписи DNS-cepвepa. Запись SIG представляет цифровую подпись записи ресурса.
В записи NXT перечислены все допустимые записи в пространстве имен.
В версии Windows Server 2012 R2 стандарты DNSSEC претерпели следующие
улучшения:
• интеграция с Active Directory и поддержка динамических обновлений DNS;
• обновленная поддержка стандартов DNSSEC (NSECЗ и RSA/SHA-2);
• проверка достоверности записей с использованием обноменных стандартов
DNSSEC;
• дополнительная поддержка DNSSEC в PowerShell.
Если вы хотите протестировать DNSSEC в испытательной среде, обратитесь к
пошаговому руководству от Microsoft, доступному по ссылке http : / /tinyurl . сот/
dnsseclab.
якори доверия
Якори доверия (trust anchors) — это открытые сертификаты серверов DNSSEC,
которым DNS-cepoep будет доверять при взаимодействии. Сертификаты якорей до
верия будут применяться для проверки достоверности цифровых подписей ответов.
Они добавляются в снойства DNS-cepвepa в форме открытых ключей.
В якори доверия Windows Server 201 2 R2 внесены следующие усовершенствова-
ния:
• использование Active Directory для распространения якорей доверия;
• поддержка автоматического перебора;
• упрошенное извлечение корневого якоря доверия.
В Windows Server 2012 R2 якори доверия отображаются о консоли DNS Manager,
внутри расположенной в левой части папки Trust Points (Точки доверия).

Поддержка преобразования именDNS на основе Интернета

В рамках организации существует также потребность в управлении пространс
твами имен Интернета. Пользователям локальной сети понадобится доступ к веб
сайтам и другим основанным на Интернете службам. Внешним пользователям будет
нужен доступ к оеб-сайтам организации и, как минимум, постовым серверам. Таким образом, вы не должны упускать из виду и эти требования.
Чтобы разрешить внешним пользователям обращаться к веб-сайтам организа
uии, должен существовать внешний домен DNS. Следовательно, вам придется об
думать вопрос о необходимости развертывания внешнего DNS-cepвepa. Внутренние
компьютеры будут преобразовывать внешние имена с помощью внутренних DNS
cepвepoo. По этой причине требуется интеграuия со структурой DNS из Интернета.

Поддержка внешних доменов DNS

Большинство компаний мя поддержки веб-сайта и электронной почты регист
рируют какое-то пространство имен DNS. Мелкие и некоторые средние компании
поручают управлять пространством имен на внешних DNS-cepвepax поставщикам
Интернет-услуг. Преимущества такого подхода связаны с готовностью серверов
и устранению потребности в обслуживании дополнительных серверов в подсети,
открытой мя Интернета. Эти серверы управляются посредством неб-интерфейса
и позволяют работать только с небольшим набором типов записей, таких как А,
CNAME и МХ.
Допускается применение сервера Windows Server 2012 R2 мя внешних операций
DNS. Роль DNS можно установить на сервере, не являющемся членом домена (как
обсуждалось в разделе «Конфигурирование автономного DNS-cepвepa» ранее в главе), и затем изменить запись сервера имен мя зарегистрированного пространства
имен DNS, указав публичный IР-адрес сервера. Конечно, открыть Интернету ав
тономный DNS-cepnep можно и таким способом, но в реальности существует не
сколько аргументов против такого подхода.
• ОС Windows Server 2012 R2 не является бесплатной, и ее использование в ка
честве внешнего решения DNS нельзя считать экономически оправданным
подходом.
• Сервер Windows Server 2012 R2 нуждается в ограничении функциональных воз
можностей и зашите, когда он открыт внешне.
• Сервер должен обладать высокой доступностью, поэтому вам придется класте
ризировать его или настроить несколько DNS-cepвepoв.
• Если вы еще об этом не позаботились, вам также понадобится высокоскорост
ное подключение к Интернету.
Общая цена, которую придется заплатить, двигаясь в таком направлении, вы
сока, поэтому многие компании предпочитают тратить свои деньги по-другому.
Именно здесь преимущество следует отдать простой реализации DNS на базе Linux.
Тем не менее, мы рекомендуем наиболее распространенный подход — поручить уп
равление внешним пространством имен поставщику Интернет-услуг.
Разделение
Когда дело доходит до DNS, многие компании также внедряют сценарий с раз
делением (spit-brain), хотя и неумышленно. Это означает, что они имеют внутреннее пространство имен, совпадающее с внешним пространством имен. Например,компания регистрирует внешнее пространство имен Eigfirrrc. corn и затем решает строить среду Active Directory с тем же самым именем.
Управление данным сценарием на единственном сервере было бы идеальным.
Реализация разделенной DNS — хорошая идея, предназначенная для решения про
блемы. Можно бьuю бы иметь один DNS-cepвep, поддерживающий внутреннюю и
внешнюю зону того же самого пространства имен. Тогда бы 1 Р-адреса мя внешней
зоны предоставлялись бы внешним запросам, а внутренние 1 Р-адреса — внутрен
ним запросам.
ПРЕДОСТЕРЕЖЕНИЯ ОТНОСИТЕЛЬНО ПРИМЕНЕНИЯ РАЗДЕЛЕННОЙ DNS
Разные специалисты и различные технические документы тто DNS могут утверждать
о том, что использовать одно и то же доменное имя для внугреннего и внешнего
пространства имен DNS компании не рекомендуется. Взамен предлагается выбрать
другое имя, которое не встречается в Интернете, или зарегистрированное имя, которым вы не пользовались.
Когда компании не следуют этой рекомендации, они вскоре обнаруживают кон
фликт при распознавании внешних ресурсов, которыми владеют, таких как www .
Bigfirm . com. Внутренний DNS-cepвep не может найти это имя, и запрос терпит
неудачу. Администраторы пытаются исправить это путем ручного добавления имени с внешним 1Р-адресом, но добавление внешнего IР-адреса вызьшает проблемы с маршрутизацией. Кроме того, разработчики будут жаловаться на невозможность загрузки нового содержимого по внешнему IР-адресу. Им нужен внугренний IР-адрес.
Такие дополнительные трудности администрирования становятся нормой при разделении DNS.
Идея неплоха, но Windows Server 201 2 R2 это не поддерживает. В первую очередь
не поддерживается организация, открывающая контроллер домена, на котором размещено внутреннее пространство имен DNS, даже на границе Интернета. Так сделано не только из соображений безопасности. База данных Active Directory слишком ценна, чтобы помещать ее в демилитаризованную зону (DMZ), где она станет лакомым кусочком для злоумышленников. Поэтому придется прибегнуть к альтернативе.
Цель заключается в том, чтобы обеспечить предоставление внешним запросам
внешних IР-адресов, а внутренним запросам — внутренних IР-адресов. Для подде
ржки такого сценария вы должны будете администрировать (минимум) два DNS
cepвepa с помощью Microsoft DNS. Ниже перечислены базовые шаги.
1. Реализуйте внешний DNS-cepвep для поддержки Bigfirrn. corn. Обычно это
становится готовым после регистрации доменного имени с помощью постав
щика Интернет-услуг.
2. Реализуйте внутреннюю структуру DNS. Это делается с применением мастера
Active Directory Domain Services lnstalation Wizard.
3. Добавьте любые внешние записи во внугреннюю зону для Bigfirrn. corn.
Помните, что DNS-cepвepы внутри сети будут авторитетными для домена
Bigfirm. corn. Если не удается найти сайт www . Bigfirrn. corn, то он не существует. Внешние записи должны быть продублированы во внутренней зоне, чтобы мог возвращаться положительный результат. Вам придется протестировать
маршрутизацию, удостоверившись в доступности указанного IР-адреса. В слу
чае возникновения проблем с маршрутизацией может понадобиться использо
вать внутренний адрес.
4. Сконфигурируйте преобразование внешних пространств имен с применени
ем корневых подсказок или серверов пересылки. Данная тема раскрывается в
следующем разделе.

Преобразование внешних пространств имен

Мы обсуждали, каким образом интегрировать DNS-cepвep с другими. Основными
методами преобразования имен DNS в Интернете являются корневые подсказки
или серверы пересылки. Корневые подсказки содержат список DNS-cepвepoв, на
ходящихся наверху структуры DNS Интернета. DNS-cepвep может взаимодейство
вать с такими серверами дЛЯ выполнения рекурсивных запросов к внешним про
странствам имен. Серверы пересылки производят ответвленные запросы к другому
DNS-cepвepy, чтобы посмотреть, не распознает ли он имя. Ранее мы упоминали,
что в небольших средах предпочитаем использовать серверы пересылки на внешний
DNS-cepвep, поддерживаемый поставщиком Интернет-услуг, но корневые подсказ
ки в данном сценарии также работают.
Важно не смешивать эти два подхода. Не определяйте в корневых подсказках
серверы как серверы пересылки. Запрос к корневой подсказке — это направленный
запрос, который всегда возвращает сервер имен лля домена. Он не отвечает записями хостов и не выполняет рекурсивную операцию, которую будет делать сервер пересылки. Кроме того, серверы пересылки имеют приоритет перед корневыми подсказками. На приведенном ранее рис. 6. 1 О вкладка Forwarders (Серверы пересылки)
содержала флажок Use root hints if по forwarders are availaЫe (Использонать корневые
подсказки, если нет доступных серверов пересылки). Вы можете сделать вывод, что если сервер пересылки указан, но получен отрицательный ответ, запрос завершится, а корневые подсказки вообще затрагиваться не будут.
В обширных внутренних средах DNS обдуманное применение серверов пере
сылки и корневых подсказок является обязательным. Внутренние серверы имен
поддоменов должны распознавать запросы от корневого DNS-cepвepa. Они также
должны распознавать запросы, основанные на И нтернете. Получая преимущес
тво возможности кеширования DNS, они могут полагаться на сервер в распозна
вании и сохранять распространен ные запросы, чтобы сократить внешний трафик.
В Microsoft рекомендуют, чтобы кеширующий сервер не был корневым, что поз
волит не перегружать корневой сервер дополнительной рабочей нагрузкой. Кроме того, в Microsoft предостерегают от прямого взаимодействия с Интернетом внутренних DNS-cepвepoв, на которых размещены зоны, чтобы уменьшить их видимость в
Интернете. На рис. 6.30 показано одно решение, которое могло бы работать с нашейвымышленной структурой DNS.
В этом примере серверы пересылки используются для отправки запросов корне
вому DNS-cepвepy в Bigfirm . com. Корневые подсказки можно было бы задейство
вать, уда,1ив корневые подсказки И нтернета и указав B F l . Bigfirm . com в качестве сервера корневых подсказок. Кеширующий сервер предотвращает отправку запросов
в Интернет DNS-серверами, на которых размещены зоны, интегрированные с Active
Directory. Он осуществляет преобразование имен посредством корневых подсказок.
Дr�я обработки запросов в домене Арех . сот применяется зона-заглушка или сервер
условной пересьшки.
Возможны другие решения, обеспечивающие преимущества по разным причи
нам. Мы отдаем предпочтение простоте использования серверон пересылки дr1я уп
равления интеграцией серверов.
Кеширующий
DNS-cepвep
Сервер пересылки
�
DNS-cepвep
Ecoast. Bigfirm.com
Зона-заглушка или
сервер условной пересылки
DNS-cepвep
Apex.com
Рис. 6.30. Внутренняя структура DNS

Администрирование и устранение неполадок с помощью инструментов DNS

В этом разделе мы обсудим доступные инструменты и приемы устранения непо
ладок в преобразовании имен DNS. Учитывая важность DNS, вы должны хорошо
знать инструменты, которые предоставляют ценную информацию, позволяющую
выявить возможные проблемы с преобразованием имен. Вдобавок к конфигурированию стандартные инструменты администрирования, консоль управления DNS и PowerShell предлагают также и дополнительную информацию такого рода. Утилиты
NsLookup, DcDiag и DNSLint предоставляют удобные начальные признаки нали
чия проблем, касающихся преобразования имен DNS.

Администрирование DNS-cepвepa с помощью консоли управления DNS и PowerShell

Для администрирования DNS-cepвepa придется иметь дело с двумя инструмен
тами: консолью управления DNS, которая является оснасткой М МС, и PoweгShell,
представляющим собой инструмент командной строки. Подобно оснастке ММС,
инструмент PowerShell предлагает возможность администрирования всего сервера, а также немного дополнительной функциональности. Например, как вы уже знаете,консоль управления DNS не позволяет изменять глобальный список блокировки запросов или создавать разделы каталога.
Повсюду в этой главе демонстрировалось применение консоли управления DNS
для создания зон и редактирования свойств серверов и зон, что является обыденными задачами, с которыми приходится иметь дело.

Вы также можете воспользоваться внутри консоли несколькими диагностически
ми конфигураuиями. Они настраиваются в свойствах DNS-cepвepa.
• Вкладка Event Logging (Ведение журнала событий). Для службы DNS создается
отдельный журнал, который можно открыть в программе просмотра событий
(Event Viewer). Он связан с консолью управления DNS. Вдобавок сервер по
умолчанию собирает все события, что настраивается на вкладке Event Logging.
+ Вкладка Debug Logging (Ведение журнала отладки). В целях анализа можно
собрать в журнале более детальные сведения о действительных коммуникаци
ях, возникающих на DNS-cepвepe. Ведение журнала отладки по умолчанию
отключено, но может быть включено через свойства DNS-cepвepa; вкладка
Debug Logging представлена на рис. 6.3 1 . Эта возможность полезна при выяв
лении причин ненадежной работы DNS-cepвepa. Хотя большинство проблем
с DNS решаются путем подходящей подключаемости IP, вы найдете данное
средство полезным, когда подключаемость IP не имеет отношения к пробле
ме. В редких случаях мы должны проверять, попадают ли специфичные запро
сы на сервер, и это средство предоставляет нужную информацию.
• Вкладка Monitoring (Мониторинг). Эта вкладка также доступна из окна свойств
DNS-cepвepa; она показана на рис. 6.32. Она позволяет проверить запросы
DNS из этого сервера или предназначенные другому серверу — обратите вни
мание, не конкретному серверу, а любому произвольно выбранному серверу.
Можно задать частоту запуска этого теста.
В выводе указывается только о том, прошел тест или нет. По существу, если на
DNS-cepвepe имеются проблемы, тест не проходит. Нам не удалось обнаружить на
этой вкладке сколько-нибудь полезные данные при решении проблем с DNS и,
скорее всего, вы не найдете здесь ничего нового. Для мониторинга DNS-cepвepoв
рекомендуется применять инструменты вроде диспетчера операций системного центра 2012 R2 (Microsoft System Center 2012 R2 Operations Manager), и эта тема обсуждается в главе 30 (том 2).
Инструмент PowerShell предлагает несколько диагностических командлетов, ко
торые могут оказаться полезными при сборе и анализе данных.
• Get-DNSServer предоставляет конфигурационные настройки для DNS
cepвepa.
• Get-DnsServer 1 Export-Clixml -Path «c: configDnsServerConfig.xml»
генерирует текстовый файл с конфигурацией и свойствами зон.
• Get-DNSServerDiagnostics предоставляет сведения о ведении журналов со
бытий для специфических операций DNS на сервере.
• Clear-DNSServerCache опустошает кеш. Иногда устаревшие распознанные
записи должны быть удалены после решения проблемы. Данная задача также
доступна в консоли управления DNS.
Все эти инструменты предоставляют средства администрирования и мониторин
га. Мы находим их полезными для проведения более глубоких исследований, когдапередовые инструменты, такие как NsLookup, DcDiag и DNSLint, не сразу указывают на проблему.

Использование NsLookup и DcDiag

При устранении проблем с DNS чаще всего используются инструменты
NsLookup, DcDiag и DNSLint. Утилита NsLookup предоставляет немедленное ука
зание на проблемы с преобразованием имен. Утилиты DcDiag и DNSLint обеспе
чивают указание на наличие проблем, связанных с Active Directory, таких как регистрация DDNS и записи SRV. Если с помощью этих инструментов не удается
идентифицировать проблему, можно положиться на средства консоли управления
DNS и PowerShell.

NsLookup
Утилита NsLookup является первым инструментом, который мы применяем при
поиске и устранении проблем с преобразованием имен. Она подключается к указан
ному в конфигурации IР-адресов основному DNS-cepвepy и делает запросы DNS.
Обратите внимание, что данная утилита не выполняет полный процесс преоб
разования имен, т.е. весь жизненный цикл. Она ограничивается одной частью этого цикла. Во время обсуждения клиентов приводились примеры команд ping и
net view, демонстрирующие различные части процесса. Пример команды ping
показывал процесс DNS, включающий первый шаг поиска имени в файле ноsтs.
Если файл ноsтs содержит записи для того же имени хоста, вы заметите расхождение между ping и NsLookup.
ВИРУС CONFICKER
Одним из примеров вредоносного ПОf использующего DNS мя нарушения нор
мальной работы, является вирус Conficker. Он появился в 2008 году, и, верите вы или нет, его до сих пор можно обнаружить на компьютерах, где не применялись
исправления системы и обновления антивирусного ПО. В зараженных вирусом
Coпficker системах предотвращается доступ из браузеров к важным сайтам внутри
определенных пространств имен DNS, таких как Microsoft . сот, Symantec . сот
и Norton . сот.
В результате ПО становится непригодным для использования. Компьютер не может
загрузить обновления Wi11dows; он не может найти возможные решения проблемы.
Даже если на машине установлено ПО Norton AntiVirus, ему не удается получить до
ступ к сайту обновлений Symantec для загрузки последних обновлений. Машина не может исправить сама себя!
Когда мы столкнулись с Co11ficker, утилита NsLookup была первым инструментом,
задействованным в процессе обнаружения проблемы. Запросы к Microsoft . сот и
Symantec . сот проходили нормально, но обращение к указанным сайтам из браузера Inteшet Explorer или Firefox оказывалось невозможным. Это помогло сузить область поиска. Таким образом, браузеры были заражены.
Конечно, утилита NsLookup предоставляет I Р-адреса мя сайтов, к которым нам необходим доступ. Однако веб-сайты Мicrosoft не функционируют в случае указания в URL только I Р-адреса. В результате такой обходной путь не срабатьmает.
Мы нашли решение с применением инструмента удаления вредоносного ПО
(Microsoft Windows Malicio11s Software Removal Tool — MSRT). Этот инструмент должен быть загружен на отдельном компьютере и затем физически перенесен на зараженный компьютер. С помощью MSRT вирус удалось идентифицировать и удалить.
К счастью, в наши дни распространение вируса Conficker ограничивается старыми ОС с устаревшим или отсутствующим антивирусным ПО и обновлениями Windows.
Тем не менее, это хороший пример того, как за счет изменения в преобразовании
имен нарушается работа системы и каким образом с помощью инструментов, подоб
ных NsLookup, найти и идентифицировать причину.
Если приложению не удается получить доступ к серверу, то после проверки
подключаемости ТСР /1 Р мы начинаем исследования с использованием команды
NsLookup.

Ниже перечислены вопросы, которые требуют прояснения.
• Отвечает ли DNS-cepвep? Команда в самом начале сообщит, можно ли под
ключиться к DNS-cepвepy. При наличии задержки или тайм-аута нет необхо
димости продолжать. Имеется проблема с подключаемостью.
• Является ли стандартный сервер неизвестным’? Это указывает на сбой обрат
ного просмотра, инициируемого утилитой NsLookup. При таком состоянии
остальные проверки NsLookup становятся бессмысленными.
• Можно ли преобразовать локальное имя FQDN’? Это обходит часть обработки
со стороны клиента. Для поиска имен хостов клиент будет добавлять основ
ные суффиксы DNS.
• Можно ли преобразовать имя хоста без суффикса DNS? Это то, что делает
клиент, и данный шаг можно проверить.
• Можно ли преобразовать внешние имена FQDN’? Это позволит проверить воз
можность выхода в Интернет стандартного DNS-cepвepa.
С утилитой NsLookup можно работать двумя способами: с помощью командных
запросов и в интерактивном режиме. Интерактивный режим намного мощнее, по
этому вначале используется именно он. Он предлагает возможность выполнять запросы к разным типам записей ресурсов и позволяет переключаться на другой сервер. Ниже приведены примеры распространенных запросов (вместе с поясняющими комментариями):
C : Use r s Ad.rninis t r ator . BFl>Nslookup
De fault Server : BFl . bigfirm . com
Address : 1 92 . 1 68 . 0 . 1 0
rem Запрос записи хоста
> BFl .bigfirm. com
Server : BFl . bigfirm . com
Address : 1 92 . 1 68 . 0 . l J
Name :
Addres s :
BFl . Ьigfirm . com
1 92 . 1 68 . 0 . 1 0
rem Запрос обратной записи PTR
> set q=ptr
> 192 . 168 . 0 . 10
Server :
l’.ddres s :
BFl . Ьigfi rm . com
1 92 . 1 68 . 0 . 1 0
10 . 1 . 1 68 . 1 92 . in-addr . a rpa
rem Запрос записи SOA
> set q=soa
> Ьigfirm . com
Server : BFl . Ьigfi rm . com
Address : 1 9 2 . 1 68 . О . 1 0
Ыgfirm . com
name = BFl . Ьigfirm . com
primary name server BFl . Ьigfirm . com
DNS и ПРЕОБРАЗОВАНИЕ ИМЕН в WINDOWS SERVER 201 2 R2
responsiЫe rnail addr = hostrnaster . bigfirm . com
serial = 124
ref resh = 900 ( 1 5 mins )
retry = 600 ( 10 min s )
expire = 8 6400 ( 1 day)
default TTL = 3600 ( 1 hour )
BFl . Ьigfirrn . сот
rem Запрос записи NS
> set <i»‘ns > bigfirrn . corn
interпet address
Server : BFl . bigfirm . com
Address : 1 92 . 1 68 . О . 1 0
1 92 . 1 68 . 0 . 1 0
bigfirm . com
BFl . Ьigfirm . com
nameserver = BFl . Ьigfirm . com
iпternet address = 1 92 . 1 68 . 0 . 1 0
rem Запрос записи SRV
> set q,zsrv
> _1dap._tcp .biqf’irm. com
Server : BFl . Ыgfir�. com
Address : 1 92 . 1 68 . 0 . 10
ldap . tcp . Ьigfirm . com SRV service locatioп :
priority О
weight 100
port 389
svr hostпame BFl . Ыgfirm . com
BFl . Ьigfirm . com iпterпet address = 1 92 . 1 68 . 0 . 1 0
DcDiaq
287
Утилита DcDiag изначально была частью набора инструментов для поддержки
администрирования (которые нужно было устанавливать отдельно) в ранних версиях Windows Server, но теперь она по умолчанию является частью установки Windows Server 2012 R2. Это инструмент, который нужно применять первым для быстрой проверки работоспособности структуры DNS. Поскольку утилита DcDiag проводит диагностику контроллеров домена, она должна проверить корректность работы DNS. После выполнения стандартного набора тестов вы можете заметить ошибки при попытках подключения к контроллерам домена. После этого можно запустить дополнительные тесты DcDiag, ориентированные специально на DNS. В следующем примере осуществляется проверка, может ли контроллер домена выполнять DDNS для регистрации записей SRV:
dcdiaq /test:ReqisterrnDNS /DnsDomain:biqf’irm. com
/f : docшnentsdcdiaqRegisterinDNS . txt
Н иже показан вывод этой команды:
Startiпg tes t : Regis teriпDNS
DNS coпfiguratioп is suf f icieпt to allow this domaiп coпtroller to
dyпamicall y register the domaiп controller Locator records i n DNS .
The DNS coпfiguration is sufficient to allow this computer to dyпarnically
register the А record correspoпdiпg to its DNS паmе .
. . . . . . . . . . . . . . . . . . . . . . . . . BFl passed test RegisteriпDNS
288
Запуск теста : Regis terinDNS
Конфигурация DNS доста точна для того, чтобы позволить этому
контроллеру домена динамически регистрировать записи Loca tor
контроллеру домена в DNS .
Конфигурация DNS достаточна для того, чтобы позволить этому
контроллеру домена динамически регистрировать запись А,
соответствующую его имени DNS .
. . . . . . . . . . . . . . . . . . . . . . . . . Brl прошел тест RegisterinDNS
Утилита DcDiag выполняет множество тестов, относящихся к контроллеру доме
на, включая несколько тестов DNS. Выше был упомянут один из таких тестов —
RegisterinDNS. Эти тесты в первую очередь сосредоточены на интеграции между
DNS-серверами внутри среды Active Directol)’. Тесты могут быть выполнены в отно
шении делегирования, серверов пересылки, обновлений и преобразовании внешних
имен DNS.
Ниже приведена часть справочной информации по утилите DcDiag. В ней при
сутствует список тестов, доступных для DNS. При тестировании преобразования
внешних имен мы обычно полагаемся на NsLookup, поэтому никогда не пользуемся
тестами /DnsForwarders и /DnsResolveExtName, но для полноты они здесь пока
заны.
DNS
Этот тест проверяет работоспособность настроек DNS для целого
предприятия . Подтесты могут запускаться по отдельности с применением
перечисленных далее ключей . По умолчанию запускаются все тесты кроме
тех , кото�:;ые проверяют преобразование внешних имен .
/DnsBas ic
/Dпs Forwarders
/DnsDelegation
/DnsDynamicUpda te
/DnsRecordRegistrat ion
/DnsResolveExtName
/DnsAll
/Dns internetName :
( базовые тесты, не могут быть пропущены)
(тесты для серверов пересылки и корневых подсказок)
( тесты для делегирования )
( тесты для динамических обновлений )
( тесты для регистрацv.и записей )
(тесты для преобразования вl-!ешних имен)
includes all tests above )
<Интер!-!ет-имя> (для теста /DnsResolveExtName )
( по умолчанию www .microsof t . com)
Как обсуждалось ранее при рассмотрении записей SRV, количество та
ких записей, зарегистрированных контроллером домена, настолько велико,
что определить на глаз, корректно ли они работают, достаточно трудно. В до
полнение к тесту / regi sterinDNS прогоняются тесты /DnsDynamicUpdate и
/DnsRecordRegistration, проверяющие регистрацию записей SRV контроллерами
доменов. В отличие от /registerinDNS, они не обязательно должны запускаться
локально на контроллере домена. Представленная ниже команда будет верифици
ровать записи SRV мя контроллера домена. Опция /v означает «verЬose» («подроб
но»). Вывод получаетсs� минным, поскольку в нем перечислены все записи SRV мя контроллера домена.
С : Jsers Administrator . БFl >dcdiag /s :BFl .Ьigfirm. com
/test : dns /dnsrecordregistration /v
DNS И ПРЕОБРАЗОВАНИЕ ИМЕН В WINDOWS 5ERVER 201 2 R2 289
Следующая команда будет проверять работоспособность обновлений DDNS мя
зоны. Она зарегистрирует хост и удалит его из зоны DNS сервера. В данном случае сервером является Ecoast . Bigfirm. сот.
C : UsersAdministrator . BFl>dcdiag /s :ecl . Ecoast . Bigfirm. com
/test:dns /dnsdynamicupdate /v
ИНСТРУМЕНТ DIG МОЩНЕЕ, ЧЕМ NsLookup
Существует инструмент для устранения неполадок в DNS, который эксплуатиру
ется в мире Unix на протяжении продолжительного времени и называется Domain
Wormation Groper (Прощупывание доменной информации), или DJG. Если вы спро
сите у пользователей DJG их мнение о том, насколько сравнима утилита NsLookup с DIG как инструмент для устранения неполадок в DNS, то не удивляйтесь, если они сначала рассмеются, после чего вежливо скажут, что они вообще несравнимы!
Однако хорошая новость в том, что DIG можно загрузить совершенно бесплатно
(http: //www . isc . org/software/Ьind) и установить в среде Windows Server 2012 R2, тем самым серьезно усилив уровень устранения неполадок в DNS. Инструмент DIG можно запускать в обычном формате командной строки, но он располагает также пакетным режимом, который поддерживает чтение запросов просмотра из файла.
Сведения по установке DIG в системе Windows Server доступны по ссылке http : / /tinyurl . com/DIGinstall. Можете также просмотреть онлайновое руководство поработе с DIG, воспользовавшись ссылкой http : //tinyurl . com/DIGusage.

Полезные ссылки по устранению неполадок в DNS

Все рассмотренные до сих пор инструменты основаны на том, что доступно в
готовом виде в ОС Windows Serveг 2012 R2. Именно с этих инструментов вы должны начинать поиск и устранение проблем в сети. В настоящем разделе мы поделимся с вами адресами нескольких веб-сайтов, имеющих отношение к DNS, которые окажут содействие в решении проблем с внешними именами DNS.
• www . IntoDNS . com. Это простой, но эффективный веб-сайт, который вы должны добавить в свой арсенал инструментов для поиска и устранения неполадок
в DNS. Когда вы достигаете домашней страницы, понадобится лишь ввести
DNS-имя домена, о котором нужно получить информацию, и щелкнуть на
кнопке Report (Отчет). В результате возвратится все доступные сведения по записям А (родительской), NS, SOA, МХ и WWW мя домена. Располагая этой
информацией, вы можете быстро идентифицировать некорректно сконфигу
рированные записи или же просто использовать ее при перекрестном контро
ле предоставленных вам сведений.
• www . мхтоо lЬо х . com. Этот сайт делает намного больше того, что заявлено на
его начальной странице. Он предназначен для содействия в поиске и устра
нении проблем с записями МХ и может оказаться полезным при попытках
выяснить, почему почтовый поток для отдельного домена электронной почты
не работает. В отношении любого домена можно запускать несколько разных
тестов, таких как просмотр МХ, проверка черного списка (Blacklist), просмотр
Whois и верификация SMTP. Если вы не пользовались этим сайтом ранее, то
самое время добавить его в список закладок.
290 ГЛАВА 6
• http://www.DNSStuff . com. Это еще один популярный сайт, который можно приме
нять мя формирования отчетов по DNS, просмотров Whois и информаuии об
1 Р-адресах. Здесь вы можете также получить доступ к большому количеству
дополнительных инструментов дЛЯ поиска и устранения проблем с DNS, если
приобретете учетную запись на нем, но сначала имеет смысл оценить обещан
ные преимущества, воспользовавшись пробным периодом.

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

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

Содержание:

1. Основные сведения
2. Немного о формате сообщения DNS
3. TCP и UDP
4. DNS в Windows Server 2008 и 2012
5. DNS и Active directory
6. Источники информации

(анкеров нет, поэтому содержание без ссылок)

1. Основные сведения

DNS — это база данных, содержащая, в основном, информацию о сопоставлении имён сетевых объектов их IP-адресам. «В основном» — потому что там и ещё кое-какая информация хранится. А точнее, ресурсные записи (Resource Records — RR) следующих типов:

А — то самое сопоставление символьного имени домена его IP адресу.

АААА — то же что А, но для адресов IPv6.

CNAME — Canonical NAME — псевдоним. Если надо чтобы сервер с неудобочитаемым именем, типа nsk-dc2-0704-ibm, на котором вертится корпоративный портал, откликался также на имя portal, можно создать для него ещё одну запись типа А, с именем portal и таким же IP-адресом. Но тогда, в случае смены IP адреса (всякое бывает), нужно будет пересоздавать все подобные записи заново. А если сделать CNAME с именем portal, указывающий на nsk-dc2-0704-ibm, то ничего менять не придётся.

MX — Mail eXchanger — указатель на почтовый обменник. Как и CNAME, представляет собой символьный указатель на уже имеющуюся запись типа A, но кроме имени содержит также приоритет. MX-записей может быть несколько для одного почтового домена, но в первую очередь почта будет отправляться на тот сервер, для которого указано меньшее значение в поле приоритета. В случае его недоступности — на следующий сервер и т.д.

NS — Name Server — содержит имя DNS-сервера, ответственного за данный домен. Естественно для каждой записи типа NS должна быть соответствующая запись типа А.

SOA — Start of Authority — указывает на каком из NS-серверов хранится эталонная информация о данном домене, контактную информацию лица, ответственного за зону, тайминги хранения информации в кэше.

SRV — указатель на сервер, держатель какого-либо сервиса (используется для сервисов AD и, например, для Jabber). Помимо имени сервера содержит такие поля как Priority (приоритет) — аналогичен такому же у MX, Weight (вес) — используется для балансировки нагрузки между серверами с одинаковым приоритетом — клиенты выбирают сервер случайным образом с вероятностью на основе веса и Port Number — номер порта, на котором сервис «слушает» запросы.

Все вышеперечисленные типы записей встречаются в зоне прямого просмотра (forward lookup zone) DNS. Есть ещё зона обратного просмотра (reverse lookup zone) — там хранятся записи типа PTR — PoinTeR — запись противоположная типу A. Хранит сопоставление IP-адреса его символьному имени. Нужна для обработки обратных запросов — определении имени хоста по его IP-адресу. Не требуется для функционирования DNS, но нужна для различных диагностических утилит, а также для некоторых видов антиспам-защиты в почтовых сервисах.

Кроме того, сами зоны, хранящие в себе информацию о домене, бывают двух типов (классически):

Основная (primary) — представляет собой текстовый файл, содержащий информацию о хостах и сервисах домена. Файл можно редактировать.

Дополнительная (secondary) — тоже текстовый файл, но, в отличие от основной, редактированию не подлежит. Стягивается автоматически с сервера, хранящего основную зону. Увеличивает доступность и надёжность.

Для регистрации домена в интернет, надо чтоб информацию о нём хранили, минимум, два DNS-сервера.

В Windows 2000 появился такой тип зоны как интегрированная в AD — зона хранится не в текстовом файле, а в базе данных AD, что позволяет ей реплицироваться на другие контроллеры доменов вместе с AD, используя её механизмы репликации. Основным плюсом данного варианта является возможность реализации безопасной динамической регистрации в DNS. То есть записи о себе могут создать только компьютеры — члены домена.

В Windows 2003 появилась также stub-зона — зона-заглушка. Она хранит информацию только о DNS-серверах, являющихся полномочными для данного домена. То есть, NS-записи. Что похоже по смыслу на условную пересылку (conditional forwarding), которая появилась в этой же версии Windows Server, но список серверов, на который пересылаются запросы, обновляется автоматически.

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

Понятно, что отдельно взятый DNS-сервер не знает обо всех доменах в интернете. Поэтому, при получении запроса на неизвестный ему адрес, например metro.yandex.ru, инициируется следующая последовательность итераций:

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

Клиент обращается к держателю зоны ru с тем же запросом.

DNS-сервер зоны RU ищет у себя в кэше соответствующую запись и, если не находит, возвращает клиенту адрес сервера, являющегося полномочным для домена второго уровня — в нашем случае yandex.ru

Клиент обращается к DNS yandex.ru с тем же запросом.

DNS яндекса возвращает нужный адрес.

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

Клиент, как правило, обращается с запросом, имеющим флаг «требуется рекурсия».

2. Немного о формате сообщения DNS

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

Заголовок состоит из следующих полей:

Формат DNS-сообщения

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

Флаги — 16-битовое поле, поделенное на 8 частей:

QR (тип сообщения), 1-битовое поле: 0 обозначает — запрос, 1 обозначает — отклик.
opcode (код операции), 4-битовое поле. Обычное значение 0 (стандартный запрос). Другие значения — это 1 (инверсный запрос) и 2 (запрос статуса сервера).
AA — 1-битовый флаг, который означает «авторитетный ответ» (authoritative answer). Сервер DNS имеет полномочия для этого домена в разделе вопросов.
TC — 1-битовое поле, которое означает «обрезано» (truncated). В случае UDP это означает, что полный размер отклика превысил 512 байт, однако были возвращены только первые 512 байт отклика.
RD — 1-битовое поле, которое означает «требуется рекурсия» (recursion desired). Бит может быть установлен в запросе и затем возвращен в отклике. Этот флаг требует от DNS сервера обработать этот запрос самому (т.е. сервер должен сам определить требуемый IP адрес, а не возвращать адрес другого DNS сервера), что называется рекурсивным запросом (recursive query). Если этот бит не установлен и запрашиваемый сервер DNS не имеет авторитетного ответа, запрашиваемый сервер возвратит список других серверов DNS, к которым необходимо обратиться, чтобы получить ответ. Это называется повторяющимся запросом (iterative query). Мы рассмотрим примеры обоих типов запросов в следующих примерах.
RA — 1-битовое поле, которое означает «рекурсия возможна» (recursion available). Этот бит устанавливается в 1 в отклике, если сервер поддерживает рекурсию. Мы увидим в наших примерах, что большинство серверов DNS поддерживают рекурсию, за исключением нескольких корневых серверов (коневые сервера не в состоянии обрабатывать рекурсивные запросы из-за своей загруженности).
0 — Это 3-битовое поле должно быть равно 0.
rcode это 4-битовое поле кода возврата. Обычные значения: 0 (нет ошибок) и 3 (ошибка имени). Ошибка имени возвращается только от полномочного сервера DNS и означает, что имя домена, указанного в запросе, не существует.

Следующие четыре 16-битных поля указывают на количество пунктов в четырех полях переменной длины, которые завершают запись. В запросе количество вопросов (number of questions) обычно равно 1, а остальные три счетчика равны 0. В отклике количество ответов (number of answers) по меньшей мере равно 1, а оставшиеся два счетчика могут быть как нулевыми, так и ненулевыми.

Пример (получен с помощью WinDump при выполнении команды ping www.ru):

IP KKasachev-nb.itcorp.it.ru.51036 > ns1.it.ru.53: 36587+ A? www.ru. (24)
IP ns1.it.ru.53 > KKasachev-nb.itcorp.it.ru.51036: 36587 1/2/5 A 194.87.0.50 (196)

Первая строка — запрос: имя моего ПК, 51036 — случайно выбранный порт отправки, 53- заранее известный порт DNS-сервера, 36587 — идентификатор запроса, + — «требуется рекурсия», А — запрос записи типа А, знак вопроса означает, что это запрос, а не ответ. В скобках — длина сообщения в байтах.

Вторая строка — ответ сервера: на указанный исходный порт с указанным идентификатором запроса. Ответ содержит одну RR (ресурсную запись DNS), являющуюся ответом на запрос, 2 записи полномочий и 5 каких-то дополнительных записей. Общая длина ответа — 196 байт.

3. TCP и UDP

На слуху сведения о том, что DNS работает по протоколу UDP (порт 53). Это действительно по умолчанию так — запросы и ответы отправляются по UDP. Однако, выше упоминается наличие в заголовке сообщения флага TC (Truncated). Он выставляется в 1, если размер отклика превысил 512 байт — предел для UDP-отклика — а значит был обрезан и клиенту пришли только первые 512 байт. В этом случае клиент повторяет запрос, но уже по TCP, который ввиду своей специфики, может безопасно передать большие объёмы данных.

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

4. DNS в Windows Server 2008 и 2012

В Windows 2008 появились следующие возможности:

Фоновая загрузка зон

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

определяются все зоны, которые должны быть загружены;
из файлов или хранилища доменных служб Active Directory загружаются корневые ссылки;
загружаются все зоны с файловой поддержкой, то есть зоны, хранящиеся в файлах, а не в доменных службах Active Directory;
начинается обработка запросов и удаленных вызовов процедур (RPC);
создаются один или несколько потоков для загрузки зон, хранящихся в доменных службах Active Directory.

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

Поддержка IPv6-адресов

Протокол Интернета версии 6 (IPv6) определяет адреса, длина которых составляет 128 бит, в отличие от адресов IP версии 4 (IPv4), длина которых составляет 32 бита.
DNS-серверы с ОС Windows Server 2008 теперь полностью поддерживают как IPv4-адреса, так и IPv6-адреса. Средство командной строки dnscmd также принимает адреса в обоих форматах. Cписок серверов пересылки может содержать и IPv4-адреса, и IPv6-адреса. DHCP-клиенты также могут регистрировать IPv6-адреса наряду с IPv4-адресами (или вместо них). Наконец, DNS-серверы теперь поддерживают пространство имен домена ip6.arpa для обратного сопоставления.

Изменения DNS-клиента

Разрешение имен LLMNR
Клиентские компьютеры DNS могут использовать разрешение имен LLMNR (Link-local Multicast Name Resolution), которое также называют многоадресной системой DNS или mDNS, для разрешения имен в сегменте локальной сети, где недоступен DNS-сервер. Например, при изоляции подсети от всех DNS-серверов в сети из-за сбоя в работе маршрутизатора клиенты в этой подсети, поддерживающие разрешение имен LLMNR, по-прежнему могут разрешать имена с помощью одноранговой схемы до восстановления соединения с сетью.
Кроме разрешения имен в случае сбоя в работе сети функция LLMNR может также оказаться полезной при развертывании одноранговых сетей, например, в залах ожидания аэропортов.

Изменения Windows 2012 в части DNS коснулись, преимущественно, технологии DNSSEC (обеспечение безопасности DNS за счет добавления цифровых подписей к записям DNS), в частности — обеспечение динамических обновлений, которые были недоступны, при включении DNSSEC в Windows Server 2008.

5. DNS и Active directory

Active Directory очень сильно опирается в своей деятельности на DNS. С его помощью контроллеры домена ищут друг друга для репликации. С его помощью (и службы Netlogon) клиенты определяют контроллеры домена для авторизации.

Для обеспечения поиска, в процессе поднятия на сервере роли контроллера домена, его служба Netlogon регистрирует в DNS соответствующие A и SRV записи.

SRV записи регистрируемые службой Net Logon:

_ldap._tcp.DnsDomainName
_ldap._tcp.SiteName._sites.DnsDomainName
_ldap._tcp.dc._msdcs.DnsDomainName
_ldap._tcp.SiteName._sites.dc._msdcs.DnsDomainName
_ldap._tcp.pdc._msdcs.DnsDomainName
_ldap._tcp.gc._msdcs.DnsForestName
_ldap._tcp.SiteName._sites.gc._msdcs. DnsForestName
_gc._tcp.DnsForestName
_gc._tcp.SiteName._sites.DnsForestName
_ldap._tcp.DomainGuid.domains._msdcs.DnsForestName
_kerberos._tcp.DnsDomainName.
_kerberos._udp.DnsDomainName
_kerberos._tcp.SiteName._sites.DnsDomainName
_kerberos._tcp.dc._msdcs.DnsDomainName
_kerberos.tcp.SiteName._sites.dc._msdcs.DnsDomainName
_kpasswd._tcp.DnsDomainName
_kpasswd._udp.DnsDomainName

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

_ldap — Active Directory является службой каталога, совместимой с LDAP-протоколом, с контроллерами домена, функционирующими как LDAP-серверы. Записи _ldap SRV идентифицирует LDAP серверы, имеющиеся в сети. Эти серверы могут быть контроллерами домена Windows Server 2000+ или другими LDAP-серверами;

_kerberos — SRV-записи _kerberos идентифицируют все ключевые центры распределения (KDC — Key Distribution Centers) в сети. Они могут быть контроллерами домена с Windows Server 2003 или другими KDC-серверами;

_kpassword — идентифицирует серверы изменения паролей kerberos в сети;

_gc — запись, относящаяся к функции глобального каталога в Active Directory.

В поддомене _mcdcs регистрируются только контроллеры домена Microsoft Windows Server. Они делают и основные записи и записи в данном поддомене. Не-Microsoft-службы делают только основные записи.

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

DomainGuid — глобальный идентификатор домена. Запись, содержащщая его, нужна на случай переименования домена.

Как происходит процесс поиска DC

Во время входа пользователя, клиент инициирует DNS-локатор, при помощи удалённого вызова процедуры (Remote Procedure Call — RPC) службой NetLogon. В качестве исходных данных в процедуру передаются имя компьютера, название домена и сайта.

Служба посылает один или несколько запросов с помощью API функции DsGetDcName()

DNS сервер возвращает запрошенный список серверов, рассортированный согласно приоритету и весу. Затем клиент посылает LDAP запрос, используя UDP-порт 389 по каждому из адресов записи в том порядке, как они были возвращены.

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

После обнаружения контроллера домена, клиент устанавливает с ним соединение по LDAP для получения доступа к Active Directory. Как часть их диалога, контроллер домена определяет к в каком сайте размещается клиент, на основе его IP адреса. И если выясняется, что клиент обратился не к ближайшему DC, а, например, переехал недавно в другой сайт и по привычке запросил DC из старого (информация о сайте кэшируется на клиенте по результатам последнего успешного входа), контроллер высылает ему название его (клиента) нового сайта. Если клиент уже пытался найти контроллер в этом сайте, но безуспешно, он продолжает использовать найденный. Если нет, то инициируется новый DNS-запрос с указанием нового сайта.

Служба Netlogon кэширует информацию о местонахождении контроллера домена, чтобы не инициировать всю процедуру при каждой необходимости обращения к DC. Однако, если используется «неоптимальный» DC (расположенный в другом сайте), клиент очищает этот кэш через 15 минут и инициирует поиски заново (в попытке найти свой оптимальный контроллер).

Если у комьютера отсутствует в кэше информация о его сайте, он будет обращаться к любому контроллеру домена. Для того чтобы пресечь такое поведение, на DNS можно настроить NetMask Ordering. Тогда DNS выдаст список DC в таком порядке, чтобы контроллеры, расположенные в той же сети, что и клиент, были первыми.

Пример: Dnscmd /Config /LocalNetPriorityNetMask 0x0000003F укажет маску подсети 255.255.255.192 для приоритетных DC. По умолчанию используется маска 255.255.255.0 (0x000000FF)

Источники информации:

www.hardline.ru/4/49/1236/1630-25.html

www.inadmin.ru/2010/02/26/dns-internet-domain

minergimn.ru/statii/16-adwin2003132

technet.microsoft.com/ru-ru/library/cc728909.aspx

support.microsoft.com/kb/247811/en-us?fr=1

В данной заметке, подробно рассмотрим процесс внедрения первого контроллера домена на предприятии. А всего их будет три:

1) Основной контроллер домена, ОС — Windows Server 2012 R2 with GUI, сетевое имя: dc1.

2) Дополнительный контроллер домена (на случай выхода из строя основного), ОС — Windows Server 2012 R2 Core, сетевое имя: dc2.

3) Контроллер домена только для чтения (RODC), находящийся в филиале компании за vpn-каналом, ОС — Windows Server 2012 R2 Core, сетевое имя: dc3.

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

Шаг 1: Установка первого контроллера домена. Подготовка.

Перед запуском мастера ролей, серверу необходимо задать сетевое имя и настроить ip-адрес. Сетевое имя — dc1. Настройки TCP/IP укажем как на скриншоте ниже.

Запускаем диспетчер сервера — Server Manager -> Dashboard -> Configure this local server -> Add Role and Features Wizard. На первом экране мастер нам сообщает, что перед тем как продолжить, должен быть установлен сложный пароль администратора, в настройках сети указан статический ip-адрес, установлены последние обновления. Если все это сделано, то нажимаем Next.

На следующем экране, выбираем первый пункт Role-based or feature-based installation (Базовая установка ролей и компонентов). Второй пункт Remote Desktop Service installtion предназначен исключительно для установки роли удаленных рабочих столов.

На экране Select Destination server диспетчер предлагает нам, выбрать сервер из пула или расположенный на VHD-диске. Поскольку у нас пока только один локальный сервер, то нажимаем Next.

Выбираем Active Directory Domain Services (Доменные службы Active Directory), после чего появится окно с предложением добавить роли и компоненты, необходимые для установки роли AD. Нажимаем кнопку Add Features и затем Next.

Обычно, на серверах с AD DS имеет смысл, параллельно разворачивать DHCP Server, поэтому отмечаем его для установки так же. Соглашаемся с установкой компонент. Нажимаем Next.

На экране Features предлагается выбрать дополнительные компоненты. На контроллере домена ничего экстраординарного обычно не требуется, поэтому нажимаем Next.

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

Службы Active Directory Domain Services требуют установленного в сети DNS-сервера. В случае если он не установлен, то роль DNS Server будет предложена для установки.

Так же, службы Active Directory Domain Services требуют установки дополнительных служб пространства имен, файловой и DFS репликации (DFS Namespace, DFS Replication, File Replication). Нажимаем Next.

На последнем экране Confirm installation selection (Подтверждение устанавливаемых компонентов), можно экспортировать конфигурацию в xml-фаил, который поможет быстро установить еще один сервер с идентичными настройками. Для этого потребуется на новом сервере, используя PowerShell, ввести следующую команду:

Install-WindowsFeature –ConfigurationFilePath
D:ConfigurationFilesDeploymentConfigTemplate.xml

или если требуется задать новое имя серверу, набираем:

Install-WindowsFeature –ConfigurationFilePath
D:ConfigurationFilesADCSConfigFile.xml -ComputerName $servername

В конце нажимаем Install. Дожидаемся окончания процесса установки.

Шаг 2: Установка первого контроллера домена. Настройка служб Active Directory, DNS, DHCP.

Теперь нажимаем на значок треугольника с восклицательным знаком и выбираем сначала Promote this server to domain controller (Повысить этот сервер до контроллера домена). Позже запустим процесс развертывания DHCP-сервера.

Запустится мастер Active Directory Domain Services Configuration Wizard (Мастер конфигурации доменных служб Active Directory). Доступно, три варианта развертывания, если:

Add New Forest — создать новый корневой домен в новом лесу. Используется для новой «чистой» установки Active Directory; (например ‘test.ru’)

Add a new domain to an existing forest — добавить новый домен в существующем лесу, возможные варианты: Tree Domain — корневой домен нового дерева в существующем лесу (например ‘test2.ru’ параллельно с ‘test.ru’) или Child Domain — дочерний домен в существующем лесу (например ‘corp.test.ru’)

Add a domain controller to an existing domain — добавить дополнительный контроллер домена в существующем домене, используется для резервного или филиального домена.

Выбираем вариант Add New Forest, задаем корневое имя домена, нажимаем Next.

На следующей вкладке можно задать функциональный уровень домена и леса (по умолчанию 2012R2), снять или отметить для установки DNS Server, и задать пароль для режима восстановления службы каталогов (DSRM). Укажем только пароль для DSRM и нажмем Далее.

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

Далее в Addional Optional соглашаемся с NetBIOS именем, которое предлагает нам система, жмем Next.

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

На следующем этапе Review Options отображается сводная информация по настройке. Кнопка View Script, позволяет посмотреть Powershell скрипт, при помощи которого, в будущем можно будет произвести настройку доменных служб Active Directory. Нажимаем Next.

И наконец, на последнем этапе предварительных проверок, если видим надпись: «All prerequisite checks are passed successfully. Click «install» to begin installation.» (Все предварительные проверки пройдены успешно. Нажмите кнопку «установить», чтобы начать установку.), то нажимаем Install, дожидаемся окончания процесса установки.

После перезагрузки, снова заходим в Server Manager -> Dashboard и запускаем пиктограмму треугольника с восклицательным знаком и выбираем там Complete DHCP Configuration (Завершение конфигурации DHCP).

Запустится мастер по конфигурированию DHCP, который нам сообщит, что будут созданы группы безопасности администратора и пользователя DHCP-сервера, и будет произведена авторизация в AD. Нажимаем Next.

На следующем экране нажимаем Commit что бы завершить процесс авторизации в Active Directory.

Если видим, что Create Security Group — Done и Authorizing DHCP Server — Done, то процесс завершился успешно, нажимаем Close.

Теперь создадим обратную зону в DNS. Обратная зона, позволяет выполнить разрешение FQDN-имен хостов по их IP-адресам. В процессе добавления ролей AD и DNS по умолчанию не создаются, поскольку предполагается, что в сети может существовать другой DNS-сервер, контролирующий обратную зону. Поэтому создадим ее сами, для этого переходим в диспетчер DNS (DNS Manager), на вкладку Reverse Lookup Zones, кликаем правой кнопкой и выбираем New Zone.

Запустится мастер DNS-зоны. Соглашаемся с параметрами по умолчанию, а именно нам предлагается создать основную зону которая будет хранится на этом сервере (Primary Zone) и будет интегрирована в Active Directory (Store the zone in Active Directory..). Нажимаем Next.

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

Для всех DNS-серверов расположенных на контроллере домена в этом лесу (То all DNS servers running on domain controllers in this forest). Репликации во всем лесу Active Directory включая все деревья доменов.

Для всех DNS-серверов расположенных на контроллере домена в этом домене (То all DNS servers running on domain controllers in this domain). Репликация внутри текущего домена и его дочерних доменов.

Для всех контроллеров домена в этом домене (То all domain controllers in this domain). Репликация на все контроллеры домена внутри текущего домена и его дочерних доменов.

На все контроллеры домена в указанном разделе каталога приложений (To all domain controllers specified in the scope of this directory partition). Репликация на все контроллеры домена, но DNS-зона располагается в специальном каталоге приложений. Поле будет доступно для выбора, после создания каталога. Подробнее.

Выбираем вариант по умолчанию, нажимаем Next. Затем выбираем протокол по умолчанию IPv4 и снова жмем Next.

На следующем экране зададим идентификатор сети (Network ID). В нашем случае 192.168.0. В поле Reverse Lookup Zone Name увидим как автоматически подставится адрес зоны обратного просмотра. Нажимаем Next.

На экране Dynamic Update (динамические обновления), выберем один из трех возможных вариантов динамического обновления.

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

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

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

Выбираем первый вариант, нажимаем Next и завершаем настройку нажатием Finish.

Еще одна полезная опция, которая обычно настраивается в DNS — это серверы пересылки или Forwarders, основное предназначение которых кэшировать и перенаправлять DNS-запросы с локального DNS-сервера на внешний DNS-сервер в сети интернет, например тот что находится у провайдера. Например мы хотим, что бы локальные компьютеры в нашей доменной сети, в сетевых настройках у которых прописан DNS-сервер (192.168.0.3) смогли получить доступ в интернет, необходимо что бы наш локальный dns-сервер был настроен на разрешение dns-запросов вышестоящего сервера. Для настройки серверов пересылки (Forwarders) переходим в консоль менеджера DNS. Затем в свойствах сервера переходим на вкладку Forwarders и нажимаем там Edit.

Укажем как минимум один IP-адрес. Желательно несколько. Нажимаем ОК.

Теперь настроим службу DHCP. Запускаем оснастку.

Сперва зададим полный рабочий диапазон адресов из которого будут браться адреса для выдачи клиентам. Выбираем ActionNew Scope. Запустится мастер добавления области. Зададим имя области.

Далее укажем начальный и конечный адрес диапазона сети.

Далее добавим адреса которые мы хотим исключить из выдачи клиентам. Жмем Далее.

На экране Lease Duration укажем отличное от по умолчанию время аренды, если требуется. Жмем Далее.

Затем согласимся, что хотим настроить опции DHCP: Yes, I want to configure these option now.

Последовательно укажем шлюз, доменное имя, адреса DNS, WINS пропускаем и в конце соглашаемся с активацией области нажатием: Yes, I want to activate this scope now. Finish.

Для безопасной работы службы DHCP, требуется настроить специальную учетную запись для динамического обновления записей DNS. Это необходимо сделать, с одной стороны для того что бы предотвратить динамическую регистрацию клиентов в DNS при помощи административной учетной записи домена и возможного злоупотребления ею, с другой стороны в случае резервирования службы DHCP и сбоя основного сервера, можно будет перенести резервную копию зоны на второй сервер, а для этого потребуется учетная запись первого сервера. Для выполнения этих условий, в оснастке Active Directory Users and Computers создадим учетную запись с именем dhcp и назначим бессрочный пароль, выбрав параметр: Password Never Expires.

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

Нажимаем Apply и затем ОК. Открываем снова консоль DHCP. Переходим в свойства протокола IPv4 на вкладку Advanced.

Нажимаем Credentials и указываем там нашего пользователя DHCP.

Нажимаем ОК, перезапускаем службу.

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

Привет.

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 (это максимальное ограничение).

Это обозначает то, что я уверен, что у меня нет ни одной записи, которая разрешается сразу в более чем 28 ответов, но если таковые есть (допустим, чужие, после рекурсивного запроса) – клиенту будет возвращаться не “сколько влезло плюс пометка, что влезло не всё”, а только 28 лучших. Сценарий с возвратом большого числа записей возможен, в принципе, в паре основных случаев – когда запрашивается разрешение имени какого-то высоконагруженного ресурса (в ответе пачка A и AAAA), или когда во внутренней сети запрашивается Active Directory-специфичная корневая или SRV запись (допустим, за корень домена в DNS регистрируются все DC – поэтому в больших доменах очевидна ситуация, когда ответ на вопрос “а кто у нас хост за domain.local” возвращает опять же большую пачку A- и AAAA-записей). В этом случае нужно оперировать настройками сервера по части приоритета выдачи только нужных ответов, а не всех, и максимально избегать линейного решения ситуации “вот тебе в ответ на запрос 250 A-ответов про все DC в домене, делай что хочешь”.

Настройка BIND secondaries

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

Для настройки этой опции нужно выбрать свойства (Properties) у сервера DNS, там – вкладку Advanced, а после выбрать соответствующий параметр:

Настройка тайм-аута AXFR / IXFR трансфера

По умолчанию трансфер DNS-зоны считается несостоявшимся, если тайм-аут со стороны отвечающего сервера превысил 30 секунд бездействия. Этот параметр можно и нужно править – например, снизить до 15 секунд, чтобы раньше “отсекать” ситуации, когда сервер не осуществляет трансфер, а просто подключился и сидит. Хорошие DNS-серверы так себя не ведут, действуют быстро и закрывают TCP-сессию тоже оперативно. Правим:

Настройка времени блокировки AXFR / IXFR трансфера

Одной из загадок в поведении Microsoft DNS Server, обнаруживаемой в начале использования, является то, что после удачной передачи зоны с одного сервера на другой, и быстрого рефреша консоли нажатием F5, вылезает ошибка “Всё, трансфер зоны сломался”. В самом деле, чему там ломаться-то в такой ситуации?

Ломаться действительно нечему – просто срабатывает механизм защиты primary DNS от перегрузки. Логика следующая:

Допустим, что у нас есть DNS-зона, которая расположена на 1 primary DNS-серверах и на 100 secondary. Притом все secondary обновляют её исключительно с primary, т.е. никакой иерархии secondary нет.
Один из secondary начинает скачивать зону. Пока он это делает, в эту же зону хочет записаться dynamic update какой-либо записи. Допускать этого нельзя, поэтому на зону на время трансфера накладывается write lock.
Зона успешно передана – write lock снят, записи в зону произведены, и primary уведомляет всех secondary (через механизм DNS Notify), что есть изменения. Все они приходят качать зону, она опять блокируется от записей.

Такие “качели” приводят к тому, что зона непрерывно крутится в цикле “накопить пачку отложенных записей – массово раздать зону”. По сути, ради каждого единичного обновления все сервера подрываются полностью передавать зону (мы ж не уверены, что у всех есть IXFR). Вот для блокировки этого и нужен данный параметр. Время блокировки считается просто – количество секунд, по факту потраченное на последний успешный трансфер зоны (параметр хранится для каждой DNS-зоны на DNS-сервере отдельно), домножается на коэффициент, и результирующее число – это тот интервал, когда все запросы на трансфер будут безусловно отвергаться (в логах у secondary вы увидите событие 6525, “primary server refuses zone transfer”). Если этот параметр установить явно в нуль, то механизм полностью выключится – вы можете сделать так в случае, если подобная защита не нужна (малое число DNS-серверов), тогда ваша зона будет актуализироваться максимально быстро. Я просто уменьшу данный параметр с 10 (значение по умолчанию) до 3 раз – т.е. если зона передаётся за 3 секунды, следующие 9 секунд все запросы на трансфер будут отклоняться.

Фильтрация Name checking

Настройка Name Checking на уровне DNS Server’а указывает на то, по каким критериям будут фильтроваться имена в запросах. То есть в случае, если имя в запросе подпадает под выбранную логику проверки – запрос обрабатывается, если нет – то считается ошибочным и отбрасывается. Вариантов настройки будет четыре:

Вариант Strict RFC (ANSI)

В запрашиваемых именах могут быть только символы, которые указаны в RFC 952 и RFC 1123. Т.е. подмножество семибитовых ASCII-символов, case insensitive, по сути – только английские буквы, цифры и минус/тире/дефис.

Вариант Non RFC (ANSI)

Strict RFC плюс подчёркивание.

Вариант Multibyte (UTF8)

Имена могут быть в Unicode (RFC 2181).

Вариант All Names

Фильтрация не производится, сервер пытается обработать все полученные строки.

Что выбрать? Тут всё достаточно сложно. Ситуаций много. Например, если ваш DNS-сервер держит исключительно внешние зоны, в которых нет хостов с именами, использующими символы национальных алфавитов, и предназначен он лишь для этой задачи (т.е. на нём нет рекурсии), то имеет смысл использовать Non RFC. Для обычного сервера, который кэширует запросы клиентов, подойдёт Multibyte. Отключать фильтрацию целиком нецелесообразно.

Фильтрация по размеру FQDN – каждый компонент не более 63 байт и все в сумме – не более 255 – всегда сохраняется и не редактируема.

Наглядный пример – то, что на картинке, может быть только на сервере, который настроен не на Strict RFC / Non RFC:

Если у данного сервера поменять настройку на Strict RFC и сделать на зоне Reload, то запись тихо пропадёт – сервер проигнорирует её при загрузке. А если после вернуть настройки на All Names и опять сделать Reload – запись опять появится.

Как настраивается фильтрация Name Checking в Windows Server 2008 R2 DNS

Для настройки этой опции нужно выбрать свойства (Properties) у сервера DNS, и там – вкладку Advanced, а после выбрать необходимый режим.

Механизм Aging/Scavenging в DNS

Динамически добавленные в DNS-зону записи не умеют пропадать сами. Это не баг, это так положено. В WINS (который NBNS) (не к ночи он будет помянут) этот механизм был штатным, а вот в DNS – увы. Поэтому фирма Microsoft добавила данный механизм в свою реализацию DNS Server. Как он будет работать?

У каждой динамически зарегистрированной записи будет указываться time stamp – время последнего успешного изменения этой записи. После, на протяжении no-refresh time (по умолчанию – 7 дней), все обновления этой записи будут игнорироваться. В оригинале, когда этот механизм был в WINS, это было нужно, чтобы информация о записи “расползлась” по инфраструктуре, сейчас делается с другими целями. Когда no-refresh time закончится, у записи начинает бежать обратный отсчёт – refresh-time. Это время, в течении которого запись должна обновиться. Если она не обновится за это время (по умолчанию – тоже 7 дней), то она является кандидатом на удаление. И вот тут-то, если на уровне сервера включен механизм Scavenging of stale records, такие записи будут удаляться. Делается это раз в сутки (если включен автоматический режим), либо вручную.

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

Не забывайте, что механизм включается и на уровне сервера, и на уровне зоны. Чтобы механизм функционировал, необходимо включить его и там и там. Т.е. и зона должна одобрять идею автоматической очистки, и конкретный сервер знать, что периодически надо удалять записи, не обновлённые уже X дней.

Включать данный механизм полезно ещё по одной причине. Мало того, что он будет удалять устаревшие записи. Он ещё будет, вводя no-refresh interval, уменьшать трафик репликации Active Directory. Т.е. если за время no-refresh interval придёт запрос на динамическое обновление записи, и в нём не будет ничего нового, кроме продления срока жизни, то без механизма aging/scavenging этот запрос будет отработан и в зону будет произведена запись (бессмысленная), что вызовет репликацию раздела Active Directory, в котором находится эта запись. А в случае, если механизм будет включен, сервер посмотрит, и если запрос не будет содержать никакой новой информации (ну, например, машину просто перезагрузили – она ту же A-запись пытается зарегистрировать, по сути – просто сбросить time stamp), он будет проигнорирован. Это никак не повлияет на качество работы DNS, а вот новую репликацию не инициирует. Профит!

Как включается Aging/Scavenging в Microsoft Windows Server 2008 R2 DNS

Первое – включаем на уровне сервера. Этот пункт находится в настройках сервера (Properties), вкладке Advanced, снизу. Время, задаваемое там – это критерий очистки. Т.е. раз в сутки сервер, на котором это включено, будет находить все динамически зарегистрированные записи, которые не обновлялись указанное в настройках время, и удалять их. Можно указать этот параметр достаточно большим – я указываю 30 дней, если рабочая станция месяц не обновляла свою запись – наверное, смысла жить в DNS ей больше нет. Вернётся – заново зарегистрирует.

Второе – включаем на уровне зоны. Задаём no-refresh и refresh интервалы. Обычно стандартное время менять не нужно. В общем, всё.

Работа Round Robin и Netmask Ordering

Оба данных механизма, в общем, преследуют предсказуемую цель – улучшить жизнь DNS-клиента, выдавая ему заранее перетасованные и (желательно) только лучшие RR-записи в ответ на запрос, на который надо вернуть большое подмножество ответов. Поэтому по умолчанию оба этих параметра включены:

Как будет вести себя DNS-сервер в зависимости от их настроек:

Если оба параметра выключены, то клиенту в ответ на запрос возвращается всегда одинаковый комплект A- и AAAA-записей, порядок их не меняется.
Если включен только Netmask Ordering, то из списка всех A- и AAAA-записей хоста будут выбраны те, у кого первые N бит совпадают с source address клиентского запроса, и эти записи будут помещены в верх списка по критерию “чем больше бит совпало, тем лучше”. Обратите внимание на то, что source address – это, в случае рекурсии, всё время одинаковый адрес вашего DNS-сервера, который форвардит запросы наружу, поэтому фактически Netmask Ordering нужен только на сервере, к которому напрямую подключаются клиенты, и хорошо подходит, допустим, для задачи “дай список DC за домен”, где клиент и DC в региональном филиале скорее всего будут в одном сегменте сети.
Если включен только Round Robin, то A- и AAAA-записи в ответе перемешиваются каждый раз, благодаря чему простые реализации DNS client’ов, которые берут первый попавшийся ответ, математически ровно распределяют попытки подключения между хостами.
Ну а если включены оба режима, то вначале отработает Netmask Ordering, а не подпавшие под него записи будут перетасованы Round Robin’ом.

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

В случае же, если вам нужно исключить какой-либо тип RR из ротации round robin – т.е. надо, чтобы записи именно этого типа отдавались клиенту вот именно в одном и том же порядке всегда – то есть специальная команда:

Посмотреть исключённые в данный момент типы записей можно как обычно, командой show dnsserver.

Блокировка динамической регистрации по типу RR

В зонах, где разрешена динамическая регистрация, возможно указание того, какие именно типы записей можно обновлять динамически, а какие – нет. Это логично – разрешая динамическое обновление зоны (что безопасное, что обычное), администратор обычно подразумевает, что туда могут регистрироваться новые хосты. А вот что можно удалённо записать произвольную SOA, NS, или сделать NS-делегирование – это, в общем, неправильно.

Для управления этим есть параметр updatetypes, текущие настройки его можно посмотреть той же командой show dnsserver:

Задавать его придётся битовой маской, где каждый бит – это разрешение или запрет для динамической регистрации определённого типа RR. В одном DWORD собраны настройки и для всех зон, поддерживающих только безопасные обновления, и для всех зон, поддерживающих обычные динамические обновления:

Практический пример применения этого параметра – допустим, у вас есть домен Active Directory с названием kontora.local. Вы хотите, чтобы все сетевые принтеры в фирме были подключены не по IP-адресам, а по DNS-именам. Принтеры умеют, получив новый адрес от DHCP, динамически зарегистрироваться в DNS – но не умеют делать это безопасно, т.к. не имеют учётной записи в Active Directory. Ради принтеров ослаблять безопасность основной DNS-зоны домена – неправильно. Можно сделать субдомен prn.kontora.local и сказать принтерам регистрироваться в нём. Но тогда неплохо бы подстраховаться, чтобы они регистрировали именно A-записи, а вот например NS чисто технически обновить было бы нельзя (чтобы не было атаки на добавление rogue-DNS, в котором под A-записями принтеров будут скрываться узлы, которые будут делать что-то нехорошее).

Настройка EDNS0 в Windows Server 2012 R2

Данный блок настроек, из-за своей неочевидности и необходимости подробно разобрать лежащие в их основе технологии, вынесен в отдельную статью на нашей Knowledge Base – https://www.atraining.ru/edns0-windows-server/. Относится он скорее к тюнингу, чем к безопасности, но это никак не снижает его нужности.

Настройка DNS-форвардеров в Windows Server

Стандартное окно, где можно добавить форвардеры – очень простое.

В случае работы с conditional forwarders, которые появились с Windows Server 2003, вам разве что добавляется возможность повлиять на тайм-аут запроса – мол, если за это время DNS-сервер не ответит, запрос считается пропавшим без вести.

Но на самом деле возможностей настройки – гораздо больше.

Командлет Set-DnsServerRecursion поможет настроить более тонкую обработку рекурсии. Какие у него будут параметры?

Параметр -SecureResponse

Данный параметр очень ценный – он будет указывать, проверять ли ответ удалённого сервера на возможность cache pollution. То есть, допустим сценарий – вы сделали conditional forwarder, который говорит, чтобы все запросы вида *.atraining.ru перенаправлялись на адрес 178.159.49.230. Обычно подобные conditional forwarder’ы используются как обеспечение разрешения партнёрских внутренних DNS-зон в рамках forest trust – поэтому простой вопрос – а есть ли смысл, чтобы хост 178.159.49.230 передавал информацию дальше, если не найдёт у себя? По идее нет – вы указываете DNS-серверы партнёра, которые являются authoritative за его зону. Вот, используя этот параметр, можно указать – как в данном случае будет вести себя ваш сервер, получив ответ – поверит в любом случае или удостоверится, что присылающий сервер является авторитативным за зону, из которой пришёл ответ.

Параметр -Timeout

Стандартный тайм-аут ответа удалённого сервера – 15 секунд. Вы можете повлиять на этот параметр – увеличив его (тогда далёкие сервера будут успевать отвечать), или уменьшив (тогда нерабочий сервер будет определяться быстрее).

Параметр -AdditionalTimeout

Это – плюсик к предыдущему параметру, показывающий, что если в запросе будет бит рекурсии, то надо дополнительно подождать – ведь удалённый сервер может куда-то сбегать и спросить. Стандартно это дополнительные 4 секунды, как у гранаты Ф1 (хотя сейчас они от 3.2 секунд бывают, так что DNS server чуток тормознее). Если настраиваете региональный DNS-сервер, который пробрасывает запросы по VPN до центрального офиса – возможно, надо увеличить данный параметр, это положительно повлияет на уменьшение false negative в кэше сервера.

Параметр -RetryInterval

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

Ускоряем загрузку DNS-зон в Windows Server 2012 R2 и старше

Hotfix 3038024 приносит новую функциональность в DNS server в Windows Server 2012 R2 и старше. Заключается она в альтернативном механизме подгрузки зон и решении проблем с “зависшим” форвардером (это когда DNS server при наличии более одного форвардера почему-то после тайм-аута первого не пробует второй). Ключевое – действует этот метод только для серверов, которые подгружают зоны из файлов, а не из Active Directory – т.е. данный приём нужен только для проксирующих и держащих внешние зоны DNS-серверов.

До установки 3038024 обязательно установите апрельский update rollup. Microsoft пишет, что хотфикс меняет загрузку зон только в случае, если DNS-сервер стартует с параметром “Load zone data on startup: From registry” (это когда BootMethod будет равен 2), по факту же работает всегда – поэтому, кстати, этот хотфикс добавлен в Windows Server 2016 сразу же, как часть функционала.

В общем, пока всё.

Заключение

Надеюсь, что данная статья поможет Вам корректно и эффективно настроить сервис DNS в инфраструктуре предприятия. Ну, а про DNSSEC (как и ранее про EDNS0) – напишем отдельно. Удач!

Возможно, вам будет также интересно почитать другие статьи про DNS на нашей Knowledge Base

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

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

Содержание

Что такое DNS и DNS сервер?
Установка DNS сервера на Windows Server 2012 R2
Шаг 1
Шаг 2
Шаг 3
Шаг 4
Шаг 5
Шаг 6
Шаг 7
Шаг 8
Создание зоны прямого просмотра на DNS сервере 2012 R2

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 адрес. И на этом предлагаю заканчивать. Удачи!

Что такое DNS?

DNS – это аббревиатура от Domain Name System. Переводится как система доменных имён, и является системой, которая сопоставляет между собой доменное имя и IP адрес хоста. Так, зная имя хоста, можно получить его адрес и наоборот. Для чего это нужно? Всемирная сеть Интернет устроена таким образом, что каждое устройство (компьютер, телефон, планшет, маршрутизатор) имеет свой уникальный адрес (на самом деле адреса могут повторяться, если речь идет о разных ЛОКАЛЬНЫХ сетях, но в данной статье мы говорим о глобальной сети и не будем вдаваться в подробности NAT, PAT и маршрутизации), и обратиться к этому устройству можно только зная его адрес в сети. Работая в Интернете, мы обращаемся к десяткам сайтов каждый день. Трудно было бы запомнить все их адреса, состоящие из последовательности номеров и точек, например, что проще запомнить 77.222.61.238 или integrus.compumur.ru? Конечно, второе. А адрес за вас вспомнит система доменных имен.

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

Как установить DNS-сервер?

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

Как установить роль DNS сервера? Установку будем проводить на Windows Server 2012 R2.

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

Откроется окно «Мастера добавления ролей и компонентов». Прочитайте вступительный текст мастера и нажмите «Далее».

Убедитесь, что выбран пункт «Установка ролей и компонентов» и нажмите «Далее».

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

Выбираем Роль DNS-сервер.

Отметив необходимый пункт галочкой, увидим появившееся окно «Мастера добавления ролей и компонентов». Эти компоненты необходимы для управления устанавливаемой ролью. В случае, если вы собираетесь администрировать DNS-сервер с другого сервера, то можно пропустить добавление данных компонентов.

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

Нажмите кнопку «Установить».

Начнется установка.

После завершения установки (установка будет длится менее 5 минут) появится надпись: «Установка выполнена на ИмяВашегоСервера». Можно нажать кнопку «Закрыть». Теперь в Панели мониторинга сервера, а также в Меню Пуск появится новая строчка «DNS». Если кликнуть по этой строчке, то запустится «Диспетчер DNS».

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

На данный момент на DNS-сервере не настроена ни одна зона. Такой сервер называется кэширующим. Зоны – это части пространства имен, за которые отвечает сервер. Зоны прямого просмотра предполагают преобразование имени в IP-адрес. Зона обратного просмотра наоборот, сопоставляет IP-адрес с именем.

Создадим зону прямого просмотра и сделаем её простую настройку.

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

Откроется окно «Мастера создания новой зоны», жмем «Далее». Откроется окно выбора типа зоны. Если у Вас нет другого сервера DNS выбирайте «Основная зона» и «Далее».

В следующем окне нужно задать имя зоны. Рекомендуется использовать ваш домен. В нашем случае в качестве имени было бы указано: integrus.compumur.ru. Жмем «Далее».

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

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

Жмем «Далее» и «Готово». Зона прямого просмотра успешно создана, проведем её простую настройку. Настройка зоны просмотра осуществляется путем добавления в зону DNS-записей. Существует несколько типов DNS-записей. Рассмотрим основные типы:

А-запись. Соотносит Имя хоста и адрес протокола IPV
АААА-запись. Соотносит Имя хоста и адрес протокола IPV
CNAME-запись. Псевдоним, используется для переадресации на другое имя.
MX-запись. Почтовая запись, указывает на почтовые сервера.
NS-запись. Указывает на DNS-сервер домена.

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

В открывшемся окне «Новый узел» вводим Имя узла, например GateWay и его IP-адрес, например 192.168.0.1. Нажмите кнопку «Добавить узел».

Готово! Запись успешно создана!

В данной статье мы постарались максимально понятным языком объяснить простому человеку без глубоких знаний IT что такое DNS, как установить роль DNS-сервера на Windows Server 2012, познакомились с основными типами записей и в картинках показали как эти записи делаются. А если все вышеописанное показалось Вам трудным, то наши специалисты настроят Вам сервер менее, чем за час.

Setting up a Domain Name System (DNS) on Windows Server involves installing the DNS Server Role. This tutorial will walk you through the DNS installation and configuration process in Windows Server 2012.

Microsoft Windows Server 2012 is a powerful server operating system capable of many different roles and functions. However, to prevent overloading production servers with features and options that are never used, Windows Server provides a modular approach in which the administrator manually installs the services needed. To setup and configure DNS, one must install the DNS Server Role on Windows Server 2012.

More: Windows Administration Tutorials

Install DNS Server Role in Server 2012

To add a new role to Windows Server 2012, you use Server Manager. Start Server Manager, click the Manage menu, and then select Add Roles and Features.

Click Next on the Add Roles and Features Wizard Before you begin window that pops up. (If you checked Skip this page by default sometime in the past, that page will, of course, not appear.)

Now, it’s time to select the installation type. For DNS servers, you will be selecting the Role-based or feature-based installation.

Next, you will choose which server you want to install the DNS server role on from the server pool. Select the server you want, and click next.

At this point, you will see a pop-up window informing you that some additional tools are required to manage the DNS Server. These tools do not necessarily have to be installed on the same server you are installing the DNS role on. If your organization only does remote administration, you do not have to install the DNS Server Tools.

However, in a crunch you may find yourself sitting at the server console or remotely using the console and needing to manage the DNS Server directly. In this case, you will wish you had the tools installed locally. Unless your company policy forbids it, it is typically prudent to install the management tools on the server where the DNS will be housed.

Now you should see the Features window. No need to make any changes here; just click Next.

Next is an informational window about DNS Server and what it does, although one would assume that if you’ve gotten this far, you are already aware of what it is. Click Next to move on.

This is the final confirmation screen before installation completes. You can check the box to Restart the destination server automatically, if you like. Installing the DNS Server does not require a restart, but unless you’ve planned for the downtime, keep that box unchecked, just in case.

The DNS Server role should now be installed on your server. There should be a new DNS Role tile in your Server Manager.

Configure DNS Server in Server 2012

If you are an old pro with DNS server files, Windows Server 2012 does let you edit the files directly. However, Microsoft recommends that you use the interface tools to avoid errors, especially if you are integrating DNS with Active Directory.

If you want to use the command line to configure your DNS, use the dnscmd command. For those of us who don’t memorize TechNet for fun, a few clicks is all it takes.

Within Server Manager, to configure the DNS Server, click the Tools menu and select DNS. This brings up the DNS Manager window.

We need to configure how the DNS server will work before adding any actual records. Select the DNS server to manage, then click the Action menu, and select Configure a DNS Server. This brings up the Configure a DNS Server wizard.

There are three options here. You can either: configure a forward lookup zone only, create forward and reverse lookup zone, or configure root hints only.

A forward lookup zone allows you to do the standard DNS function of taking a name and resolving it into an IP address.

A reverse lookup zone allows you to do the opposite, taking an IP address and finding its name. For example, if a user is set up to print to a printer with an IP address of 10.20.12.114, but you need to know what name that printer goes by so you can find it, a reverse lookup can help. («Ah, hah! It’s you Third Floor Vending Room Printer #1. Why you give me so much trouble?)

Root hints only will not create a database of name records for lookups, but rather will just have the IP addresses of other DNS servers where records can be found. If you already have DNS setup on your network, you’ll probably want to continue using the same configuration you already have. If not, use forward and backward for most situations. (Backup zones typically don’t hurt anything, and they are nice to have when the need arises.)

After you’ve made your section, click Next.

Now, you choose whether this server will maintain the zone, or if this server will have a read-only copy of the DNS records from another server.

Next enter your zone name. If this is your first DNS server, then this needs to be the root zone name for your entire organization. For example, my zone name might be arcticllama.com. If however, this server will be authoritative only for a subset, and other DNS servers will be responsible for other zones, then the name will need to reflect that. For example, us.arcticllama.com would be the zone name for just the American part of my vast corporate empire Click next when you have entered the name.

Now, you need to choose the file name where the DNS records will be stored. The default filename is to add a .dns extension to the name of the zone you chose in the previous window. Unless you have a corporate policy stating otherwise, stick with the convention to make things easier on yourself down the line.

Next you select how this server will respond to Dynamic Updates. Although there are three choices here, only two should actually be used in production. Select the first option to allow only secure dynamic updates if you are integrating your DNS with Active Directory. Select do not allow dynamic updates if your DNS is not integrated with Active Directory and you don’t want to allow dynamic updates. Do not allow unsecured dynamic updates unless you really know what you are doing and have a very good reason for doing so.

Up next is the option to configure forwarders. If your DNS server ever gets a query for which it has no record, it can forward that request on to another DNS server to see if it has the answer.

For example, in order to provide name resolution for internet connectivity, you can input your ISP name servers here, or use a DNS provider such as OpenDNS. You can (and should) have more than one server listed in case a DNS server is unreachable for some reason. The order forwarders are listed in is the order they are tried, so place your faster and most reliable forwarder at the top of the list.

Click Next and your DNS server is now configured and ready for use.

How to Join Windows 8.1 to a Domain
System Center 2012 R2: Worth The Upgrade?
Windows Server 2012: An Overview of New Features

Get instant access to breaking news, in-depth reviews and helpful tips.

Источник

Сегодня я расскажу Вам, как включить и выключать динамические обновления DNS в Windows Server 2008.

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

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

1. В консоли Диспетчер DNS (DNS Manager) щелкните правой кнопкой домен или подсеть, которую хотите настроить, и в контекстном меню выберите Свойства (Properties).

2. На вкладке Общие (General) в раскрывающемся списке Динамическое обновление (Dynamic Updates) выберите один из вариантов для включения или отключения динамических обновлений:

• Никакие (None) Отключение динамических обновлений.

• Небезопасные и безопасные (Nonsecure And Secure) Включение небезопасных и безопасных обновлений.

• Только безопасные (Secure Only) Включение динамических обновлений с использованием системы безопасности Active Directory. Доступно только при интеграции с Active Directory.

3. Щелкните ОК.

Если Вы подбираете себе сотовый телефон, советую Вам купить Samsung I9250, хорошая модель от Samsung. На борту пяти мегапиксельная камера, самый последний Android 4.0 Ice Cream Sandwich, двухядерный процессор — в общем всё, чтобы комфортно чувствовать себя со своим телефоном.

Источник

Настроим DNS-сервер пошагово.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проверка

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

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

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

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

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

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

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

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

Новые и измененные функции DNS в Windows Server 2016

В Windows Server 2016 DNS-сервер предлагает обновления в следующих областях:

Политики DNS-серверов

Теперь вы сможете использовать:

DNS-политики для управления трафиком на основе геолокации
Интеллектуальные ответы DNS в зависимости от времени суток, для управления одним DNS-сервером, настроенным для развертывания с разделением
Применять фильтры к DNS-запросам и многое другое.

Конкретное описание данных возможностей:

Вы также можете использовать политики DNS для зон DNS, интегрированных с Active Directory.

Ограничение скорости отклика (RRL)

Белые домены. Это список доменов, которые нужно исключить из настроек RRL.

Белые подсети. Это список подсетей, которые необходимо исключить из настроек RRL.

Аутентификация именованных объектов на основе DNS (DANE)

Поддержка неизвестных записей

Корневые подсказки IPv6

Доработка поддержки Windows PowerShell

В Windows Server 2016 представлены следующие новые командлеты (cmdlets) и параметры Windows PowerShell:

Add-DnsServerRecursionScope – Этот командлет создает новую область рекурсии на DNS-сервере. Области рекурсии используются политиками DNS для указания списка серверов пересылки, которые будут использоваться в запросе DNS.

Remove-DnsServerRecursionScope – Этот командлет удаляет существующие области рекурсии.

Set-DnsServerRecursionScope – Этот командлет изменяет параметры существующей области рекурсии.

Get-DnsServerRecursionScope – Этот командлет извлекает информацию о существующих областях рекурсии.

Add-DnsServerClientSubnet – Этот командлет удаляет существующие подсети DNS-клиентов.

Set-DnsServerClientSubnet – Этот командлет изменяет параметры существующей подсети DNS-клиента.

Get-DnsServerClientSubnet – Этот командлет извлекает информацию о существующих подсетях DNS-клиентов.

Add-DnsServerQueryResolutionPolicy – Этот командлет создает новую политику разрешения запросов DNS. Политики разрешения запросов DNS используются для указания того, как и следует ли отвечать на запрос на основе различных критериев.

Remove-DnsServerQueryResolutionPolicy – Этот командлет удаляет существующие политики DNS.

Set-DnsServerQueryResolutionPolicy – Этот командлет изменяет параметры существующей политики DNS.

Get-DnsServerQueryResolutionPolicy – Этот командлет извлекает информацию о существующих политиках DNS.

Enable-DnsServerPolicy – Этот командлет включает существующие политики DNS.

Disable-DnsServerPolicy – Этот командлет отключает существующие политики DNS.

Add-DnsServerZoneTransferPolicy – Этот командлет создает новую политику передачи зоны DNS-сервера. Политики передачи зоны DNS определяют, следует ли отклонять или игнорировать передачу зоны на основе различных критериев.

Remove-DnsServerZoneTransferPolicy – Этот командлет удаляет существующие политики передачи зон DNS-сервера.

Set-DnsServerZoneTransferPolicy. – Этот командлет изменяет параметры существующей политики переноса зоны DNS-сервера.

Get-DnsServerResponseRateLimiting – Этот командлет извлекает параметры RRL.

Set-DnsServerResponseRateLimiting – Этот командлет изменяет настройки RRL.

Add-DnsServerResponseRateLimitingExceptionlist – Этот командлет создает список исключений RRL на DNS-сервере.

Get-DnsServerResponseRateLimitingExceptionlist – Этот командлет извлекает списки исключений RRL.

Remove-DnsServerResponseRateLimitingExceptionlist – Этот командлет удаляет существующий список исключений RRL.

Set-DnsServerResponseRateLimitingExceptionlist – Этот командлет изменяет списки исключений RRL.

Add-DnsServerResourceRecord – Этот командлет был обновлен для поддержки неизвестного типа записи.

Get-DnsServerResourceRecord – Этот командлет был обновлен для поддержки неизвестного типа записи.

Remove-DnsServerResourceRecord – Этот командлет был обновлен для поддержки неизвестного типа записи.

Set-DnsServerResourceRecord – Этот командлет был обновлен для поддержки неизвестного типа записи.

Источник

Добавьте DHCP-сервер в группу безопасности DnsUpdateProxy.

Укажите учетные данные для защиты динамического обновления DNS.

Similar Posts:

Step 1 – Set DHCP server to always dynamically update records

Step 2 — Add the DHCP server to DnsUpdateProxy security group

Step 3 – Provide credential to secure the DNS dynamic update

Step 4 — Configure name protection

Порядок настройки DNS-сервера на Windows Server 2012 R2

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

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

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

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

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

Проверка

Описание функции Domain Name System (DNS), которые являются новыми или измененными в Windows Server 2016.

Политики DNS-серверов

Ограничение скорости отклика (RRL)

Аутентификация именованных объектов на основе DNS (DANE)

Поддержка неизвестных записей

Корневые подсказки IPv6

Доработка поддержки Windows PowerShell

Содержание

Установка DNS

Конфигурирование автономного DNS-cepвepa

Интеграция с другими DNS-серверами

Реализация зон для управления пространствами имен

Типы записей

Управление клиентами DNS и преобразованием имен

Система DNS в Active Directorv

Автоматическое конфигурирование DNS

Записи SRV и клиенты

Дополнительные компоненты Windows Server 2012 R2

Поддержка преобразования именDNS на основе Интернета

Поддержка внешних доменов DNS

Преобразование внешних пространств имен

Администрирование и устранение неполадок с помощью инструментов DNS

Администрирование DNS-cepвepa с помощью консоли управления DNS и PowerShell

Использование NsLookup и DcDiag

Полезные ссылки по устранению неполадок в DNS

Содержание:

1. Основные сведения

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

2. Немного о формате сообщения DNS

Формат DNS-сообщения

3. TCP и UDP

4. DNS в Windows Server 2008 и 2012

Фоновая загрузка зон

Поддержка IPv6-адресов

Изменения DNS-клиента

5. DNS и Active directory

Как происходит процесс поиска DC

Источники информации:

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

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

Настройка SocketPool

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

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

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

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

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

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

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

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

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

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

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

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

Настройка BIND secondaries

Настройка тайм-аута AXFR / IXFR трансфера

Настройка времени блокировки AXFR / IXFR трансфера

Фильтрация Name checking

Вариант Strict RFC (ANSI)

Вариант Non RFC (ANSI)

Вариант Multibyte (UTF8)

Вариант All Names

Как настраивается фильтрация Name Checking в Windows Server 2008 R2 DNS

Механизм Aging/Scavenging в DNS

Как включается Aging/Scavenging в Microsoft Windows Server 2008 R2 DNS

Работа Round Robin и Netmask Ordering

Блокировка динамической регистрации по типу RR