Как проверить работу 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-сервера

Установка роли 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-сервера на 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 – важная инфраструктурная служба. Настолько, что в предыдущей статье на тему безопасности 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) – напишем отдельно. Удач!

Hi,

We have 3 domains, 1 root and 2 child domains in the same forest, all DCs/DNS servers were 2008R2 and the forest and domain levels were also 2008R2, all was working fine. We’ve introduced 1 2012R2 DC/DNS in the root domain and 2 in into our main production
child domain. 

If we set the 2008R2 servers as DNS servers on a client their doesn’t seem to be any issues, if we set a client to use one or both of the 2012R2 servers as their DNS they resolve all of the address in the same domain ok but if they try and access a resource
in the root domain or the other child domain they usually get a DNS time out, occasionally it works but mostly not.

So for example if we ping the root domain or one of its DCs by its FQDN from a client PC in the child domain with the new DCs configured as DNS servers the usual response is
«Ping request could not find the host «FQDN». Please check the name and try again.
Occasionally this works and responds with a successful ping result. If we do the same test from the same PC but use the 2008R2 DNS servers it resolves and responds correctly every time.

I’ve ran the Microsoft best practice analyser on one of the problem DNS servers, the only error it finds is «The DNS server must resolve names in the forest root domain name zone» If I do an nslookup on the root domain from one of the 2012R2
DNS servers in the child domain this is the output:

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
Non-authoritative answer
Name: FQDN of server
Address: server IP

If I do the same NSLookup query on one of the 2008R2 DNS servers in the same domain it responds immediately with 

Non-authoritative answer
Name: FQDN of server
Address: server IP

I’ve upgraded the domain from 2003 to 2008R2 in the past without any issue.

All of the reserve lookup zones are setup and working correctly

Each DNS server is configured to point to another one as its primary DNS server and its self as the secondary server.

We’ve been through the DNS configuration a number of times now comparing all of the DNS servers and cant see any difference. Does anyone have an idea as to what has gone wrong?

Thanks,

Hi,

We have 3 domains, 1 root and 2 child domains in the same forest, all DCs/DNS servers were 2008R2 and the forest and domain levels were also 2008R2, all was working fine. We’ve introduced 1 2012R2 DC/DNS in the root domain and 2 in into our main production
child domain. 

If we set the 2008R2 servers as DNS servers on a client their doesn’t seem to be any issues, if we set a client to use one or both of the 2012R2 servers as their DNS they resolve all of the address in the same domain ok but if they try and access a resource
in the root domain or the other child domain they usually get a DNS time out, occasionally it works but mostly not.

So for example if we ping the root domain or one of its DCs by its FQDN from a client PC in the child domain with the new DCs configured as DNS servers the usual response is
«Ping request could not find the host «FQDN». Please check the name and try again.
Occasionally this works and responds with a successful ping result. If we do the same test from the same PC but use the 2008R2 DNS servers it resolves and responds correctly every time.

I’ve ran the Microsoft best practice analyser on one of the problem DNS servers, the only error it finds is «The DNS server must resolve names in the forest root domain name zone» If I do an nslookup on the root domain from one of the 2012R2
DNS servers in the child domain this is the output:

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
Non-authoritative answer
Name: FQDN of server
Address: server IP

If I do the same NSLookup query on one of the 2008R2 DNS servers in the same domain it responds immediately with 

Non-authoritative answer
Name: FQDN of server
Address: server IP

I’ve upgraded the domain from 2003 to 2008R2 in the past without any issue.

All of the reserve lookup zones are setup and working correctly

Each DNS server is configured to point to another one as its primary DNS server and its self as the secondary server.

We’ve been through the DNS configuration a number of times now comparing all of the DNS servers and cant see any difference. Does anyone have an idea as to what has gone wrong?

Thanks,

DNS (Domain Name System) – система доменных имен. В статье Настройка простой (одноранговой) локальной сети мы задавали IP адреса компьютеров и использовали их для удаленного подключения. Если простейшая сеть состоит (минимум) из двух компьютеров, то нет проблем, все ОК и хорошо.

Но, представим, что наша сеть разрослась до сотни, тысячи десятков тысяч и более компьютеров. Суть DNS в том, что DNS хранит данные о соответствии IP-адреса домену. То есть каждому IP-адресу, состоящему из цифр, соответствует буквенное имя, домен (Domain).

Благодаря DNS в компьютере хранится таблица соответствия вида «Имя домена» = «IP-адрес».

Так же система доменных имен удобнее визуально, согласитесь проще запомнить имя mycomp чем IP-адрес 192.168.1.1 , особенно если таких компьютеров много. Например, компьютер бухгалтера можно назвать compbuh и не запоминать его IP-адрес.

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

DHCP (англ. Dynamic Host Configuration Protocol — протокол динамической настройки узла) – это сетевой протокол, который позволяет получать устройствам, например компьютерам, IP-адреса автоматически.

Например, у вас дома стоит роутер, который раздает интернет. У вас есть компьютер и ноутбук. Именно DHCP раздает вашим устройствам (компьютеры, ноутбуку, смартфону) IP-адреса. Именно IP-адреса позволяют устройствам обмениваться информацией с роутером, благодаря чему на устройствах есть интернет.

Рассмотрим установку DNS на Windows Server 2012.

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

На следующей странице установите флажок «Пропускать эту страницу по умолчанию» и нажмите «Далее».

В окне «Выбор типа установки» нажмите «Далее».

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

Далее нужно выбрать, какие роли необходимо устанавливать, соответственно нужно установить роль DNS сервера, поэтому выбирается он. Нажимаем «Далее».

Выбор компонентов уже осуществлен, нажимаем «Далее».

Далее появляется информация, на что обратить внимание при установке роли DNS сервера, нужно нажать «Далее».

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

После чего запускается процесс установки, который длится около 3 минут.

Дождитесь завершения установки и нажмите кнопку «Закрыть».
Роль сервера DNS-сервер установлена. Для запуска средств управления DNS сервером нужно использовать Диспетчер серверов -> Средства -> DNS.

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

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

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

Затем нужно выбрать «Тип динамического обновления» на время такой функционал стоит запретить. Жмем «Далее»  и «Готово».

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

Далее отключаем брандмауэр Windows Server:  Центр управления сетями и общим доступом -> Брандмауэр Windows (слева внизу) -> Включение и отключение брандмауэра Windows — > отключаем для всех типов сетей.

Далее задаем IP-адрес сервера. Проверяем созданную зону.

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

Администрирование инфраструктуры Active Directory — это непростой процесс. От правильного взаимодействия серверов зависит работа всей корпоративной сети, даже если у вас всего парочка контроллеров домена и один локальный сайт.

Утилита dcdiag позволяет выполнять различные тесты над инфраструктурой Active Directory и запрашивать диагностическую информацию о контроллерах домена.

Синтаксис dcdiag

Общий синтаксис

dcdiag [/s:<DomainController>] [/n:<NamingContext>] [/u:<Domain><UserName> /p:{* | <Password> | ""}] [{/a | /e}] [{/q | /v}] [/i] [/f:<LogFile>] [/c [/skip:<Test>]] [/test:<Test>] [/fix] [{/h | /?}] [/ReplSource:<SourceDomainController>]

Параметры dcdiag:

• /s:<DomainController>
  Указывает контроллер домена. Если не указано, то используется локальный контроллер домена. Не используется в тестах DcPromo и RegisterInDns, которые можно выполнить только локально.
• /n:<NamingContext>
  Контекст именования в форматах NetBIOS, DNS (FQDN), DN.
• /u:<Domain><UserName> /p:{* | <Password> | «»}
  Запускает dcdiag от имени другого пользователя. По умолчанию dcdiag выполняется от имени текущего пользователя.
• /a
  Тестировать все серверы указанного сайта.
• /e
  Тестировать все серверы леса, перекрывает /a.
• /q
  Тихий режим. Выводятся только ошибки.
• /v
  Подробный режим. Выводится дополнительная информация.
• /i
  Игнорировать некритичные ошибки.
• /fix
  Только для теста MachineAccount. Исправление некорректных Service Principal Names (SPNs) на контроллере домена.
• /f:<LogFile>
  Вывод результатов в лог.
• /c
  Выполняет все тесты, кроме DCPromo и RegisterInDNS. Включает тесты не по умолчанию: Topology, CutoffServers, OutboundSecureChannels. Можно использовать совместно со /skip для пропуска определённых тестов.
• {/h | /?}
  Помощь.
• /test:<Test>
  Выполнить указанный тест. Дополнительно выполняется тест Connectivity.
• /ReplSource:<SourceDomainController>
  Только для теста CheckSecurityError. Проверяет соединение между контроллером домена, на котором выполняется команда, и исходным контроллером домена. SourceDomainController — это NetBIOS, DNS (FQDN) или DN имя сервера, который будет исходным контроллером домена для репликации.

Синтаксис для теста DNS

dcdiag /test:DNS [/DnsBasic | /DnsForwarders | /DnsDelegation | /DnsDynamicUpdate | /DnsRecordRegistration | /DnsResolveExtName [/DnsInternetName:<InternetName>] | /DnsAll] [/f:<LogFile>] [/x:<XMLLog.xml>] [/xsl:<XSLFile.xsl> or <XSLTFile.xslt>] [/s:<DomainController>] [/e] [/v]

Параметры dcdiag для теста DNS:

• /test:DNS
  Тест DNS. По умолчанию /DnsAll.
• /DnsBasic
  Основные тесты DNS, соединение, конфигурация DNS клиента, доступность службы, существование зоны.
• /DnsForwarders
  Тесты DnsBasic и DNS-форвардинг.
• /DnsDelegation
  Тесты DnsBasic и проверка делегирования.
• /DnsDynamicUpdate
  Тесты DnsBasic и пределяет, включено ли динамическое обновление в зоне Active Directory.
• /DnsRecordRegistration
  Тесты DnsBasic tests и также проверяет, зарегистрированы ли записи A, CNAME и службы SRV. Кроме того, создается отчет об инвентаризации на основе результатов тестирования.
• /DnsResolveExtName **[/DnsInternetName:<**InternetName>]
  Тесты DnsBasic и делает resolve InternetName. Если DnsInternetName не указано, делает resolve www.microsoft.com. Если DnsInternetName указано, делает resolve указанного InternetName.
• /DnsAll
  Все тесты кроме DnsResolveExtName и создает отчет.
• **/f:<**LogFile>
  Вывод результатов в лог.
• **/s:<**DomainController>
  Указывает контроллер домена. Если не указано, то используется локальный контроллер домена.
• /e
  Все тесты DNS для всех контроллеров домена леса.
• /v
  Подробный режим. Выводится дополнительная информация.
• /x:<XMLLog.xml>
  Вывод результатов в <XMLLog.xml>. Только вместе с опцией /test:dns.
• /xsl:<XSLFile.xsl> или <XSLTFile.xslt>
  Добавляем файл стилей. Только вместе с опцией /test:dns /x:<XMLLog.xml>.

Тесты dcdiag

Тесты, которые нельзя пропустить

• Connectivity
  Проверяет регистрацию DNS, ping, LDAP RPC для каждого контроллера домена.

Тесты, которые можно пропустить

• Replications
  Проверяет возможность репликации между контроллерами домена и сообщает об ошибках репликации.
• NCSecDesc
  Проверяет, что дескрипторы безопасности в головках контекста именования имеют соответствующие разрешения для репликации.
• NetLogons
  Проверяет наличие соответствующих привилегий входа в систему для репликации.
• Advertising
  Проверяет, правильно ли контроллер домена сообщает о себе и о своих ролях, которые он должен выполнять. Этот тест завершиться неудачно, если служба NetLogon не запущена.
• KnowsOfRoleHolders
  Проверяет доступность контроллеров домена с ролями FSMO.
• Intersite
  Проверяет наличие ошибок, которые могут помешать нормальной репликации между сайтами. Результаты могут быть неточными.
• FSMOCheck
  Проверяет, что контроллер домена может подключиться к KDC, NTP, предпочтительному NTP, PDC, серверу глобального каталога.
• RidManager
  Проверяет RID мастера.
• MachineAccount
  Проверяет службы и регистрацию учетной записи целевого компьютера. Если обнаружена ошибка, ее можно исправить, указав параметры /FixMachineAccount или /RecreateMachineAccount.
• Services
  Проверяет службы контроллера домена.
• OutboundSecureChannels
  Проверяет наличие безопасных каналов между всеми контроллерами домена.
• ObjectsReplicated
  Проверяет правильность репликации Machine Account и Directory System Agent (DSA). Можно использовать **/objectdn:**dn и **/n:**nc параметры.
• frssysvol
  Проверяет FRS и SYSVOL.
• frsevent
  Проверка ошибок системы репликации.
• kccevent
  Проверка KCC.
• systemlog
  Проверка лога на наличие ошибок.
• CheckSDRefDom
  Проверяет, что все разделы каталога приложений имеют соответствующие домены ссылок на дескрипторы безопасности.
• VerifyReplicas
  Проверяет разделы каталога приложения на всех серверах, принимающих участие в репликации.
• CrossRefValidation
  Проверяет правильность перекрестных ссылок для доменов.
• VerifyReferences
  Проверяет, что системные ссылки не повреждены для FRS и репликации.
• VerifyEnterpriseReferences
  Проверяет, что системные ссылки не повреждены для FRS и репликации во всех объектах на каждом контроллере домена.
• /skip:<Test>
  Пропускает указанный тест. Connectivity выполняется всегда.

Тесты, которые не выполняются по умолчанию

• Topology
  Проверяет, что KCC генерирует правильную топологию для всех контроллеров домена.
• CheckSecurityError
  Отчет об общем состоянии репликации в отношении безопасности Active Directory на контроллерах домена под управлением Windows Server 2003 SP1. Вы можете выполнить этот тест для одного или всех контроллеров домена на предприятии. По завершении теста dcdiag представляет сводку результатов, а также подробную информацию по каждому протестированному контроллеру домена и диагностику ошибок безопасности, о которых сообщил тест.
  Cледующий аргумент является необязательным:
  **/ReplSource:**SourceDomainController
  Этот аргумент проверяет возможность создания связи репликации между реальным или потенциальным контроллером домена-источника (SourceDomainController) и локальным контроллером домена.
• CutoffServers
  Проверяет есть ли серверы репликации без партнёра.
• DNS
  Включает шесть дополнительных тестов. Имеет отдельный синтаксис, См. выше.

Тесты не для контроллеров домена

• DcPromo
  Проверяет инфраструктуру DNS для любого компьютера, который вы хотите сделать контроллером домена. Если инфраструктура достаточна, вы можете сделать компьютер контроллером домена, указанном в параметре **/DnsDomain:**Active_Directory_Domain_DNS_Name. Этот параметр сообщает, требуются ли какие-либо изменения в существующей инфраструктуре DNS. Обязательным аргументом является **/DnsDomain:**Active_Directory_Domain_DNS_Name. Требуется один из следующих аргументов: /NewForest, /NewTree, /ChildDomain, /ReplicaDC. Если указан аргумент /NewTree, необходимо также указать аргумент **/ForestRoot:**Forest_Root_Domain_DNS_Name.
• RegisterInDNS
  Проверяет, может ли этот контроллер домена зарегистрировать Domain Controller Locator DNS записи. Эти записи должны присутствовать в DNS для других компьютеров, чтобы найти этот контроллер домена для домена Active_Directory_Domain_DNS_Name. Этот параметр сообщает, требуются ли какие-либо изменения в существующей инфраструктуре DNS. Обязательным аргументом является **/DnsDomain:**Active_Directory_Domain_DNS_Name.

Пример

Давайте продиагностируем какой-нибудь контроллер домена.

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

Проверим корректность работа DNS:

dcdiag /s:ilab-dc /test:dns /e

Все тесты пройдены успешно.

Ссылки

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc731968(v=ws.11)