Как работает dns windows server

Время на прочтение
11 мин

Количество просмотров 98K

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

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 (domain name system, служба доменных имен) — это стандартный протокол, позволяющий пользователям получать доступ к веб-сайтам, используя удобные для прочтения адреса. DNS позволяет ввести адрес веб-сайта и автоматически определить его IP-адрес, то есть уникальный идентификатор конкретного устройства (сервера) в компьютерной сети. При этом протокол DNS может обеспечивать соответствие нескольких доменных имен одному IP-адресу (что используется для виртуального хостинга), а также соответствие одному доменному имени может нескольких IP-адресов (чтобы распределить нагрузку на несколько серверов).

Что такое DNS-серверы и какова их роль

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

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

Возврат IP-адреса хоста в ответ на запрос доменного имени называют преобразованием его доменного имени в IP-адрес. Когда все работает хорошо, этот процесс занимает не более секунды.

Какие бывают DNS-серверы

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

Уровни регистрации домена на иерархических DNS-серверах делят их на:

• корневые серверы, в которые вносятся описания всех основных зон всемирной сети (.com, .org, .net, .ru, .bi);
• серверы, которые содержат списки доменов для каждой зоны в отдельности (например, DNS, в котором лежит список всех .com доменов);
• серверы подзон (в частности, для рунета) со своими отдельными DNS.

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

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

Кроме того, бывают еще авторитативные серверы DNS — это серверы, которые обслуживают строго одну зону (например, сервер, который обслуживает строго зону .ru, или корпоративный авторитативный сервер, который обслуживает исключительно зону .mail.ru). Такие серверы службы DNS работают быстрее, чем серверы общего назначения — они занимаются запросами в одной зоне, поэтому способны отвечать на них очень быстро.

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

Топ лучших публичных DNS-серверов

В десятку самых популярных публичных DNS-серверов входят:

• публичный DNS-сервер Google — один из самых быстрых серверов, который обеспечивает высокий уровень безопасности и удобство работы на своем компьютере. Чтобы использовать общедоступные DNS-серверы Google, необходимо настроить параметры сети со следующими IP-адресами: 8.8.8.8 (в качестве предпочитаемого DNS-сервера) и 8.8.4.4 (в качестве альтернативного DNS-сервера);
• OpenDNS — облачный сервер, который помогает защитить компьютер от вредоносных атак. Этот сервер существует в двух решениях — OpenDNS Family Shield и OpenDNS Home. OpenDNS Home поставляется с настраиваемой защитой от кражи и фишинга. Чтобы использовать OpenDNS, параметры сети настраиваются со следующими IP-адресами: 208.67.222.222 и 208.67.222.220;
• Norton ConnectSafe — облачный DNS-сервис, который поможет защитить компьютер от фишинговых сайтов и поставляется с тремя заранее определенными политиками фильтрации содержимого. Чтобы использовать его, в настройках сети необходимо настроить разные DNS-серверы со следующими IP-адресами — предпочитаемый DNS-сервер: 208.67.222.123 и альтернативный DNS-сервер: 208.67.220.123;
• Comodo Secure DNS — служба сервера доменных имен, которая проводит DNS-запросы через множество глобальных DNS-серверов. Этот сервер обеспечивает гораздо более быстрый и лучший опыт работы в Интернете, чем использование стандартных DNS-серверов. Для использования Comodo Secure DNS нужно изменить основной и дополнительный IP-адреса на 8.26.56.26 и 8.20.247.20;
• Level 3 — DNS-сервер, который работает на уровне 3 связи. Чтобы воспользоваться этим сервером, параметры сети настраиваются с помощью следующих IP-адресов DNS: 209.244.0.3 и 208.244.0.4;
• DNS Advantage — один из самых быстрых DNS-серверов, обеспечивающих наилучшую производительность при работе в Интернете. Он позволяет загружать сайты быстрее и безопаснее. Чтобы его использовать, настраивают предпочтительные/ альтернативные DNS-серверы со следующими IP-адресами: 156.154.70.1 и 156.154.71.1;
• OpenNIC — хорошая альтернатива для замены DNS-серверов по умолчанию и для соблюдения политики конфиденциальности. Для использования этой службы предпочтительные и альтернативные DNS-серверы настраивают по адресам 46.151.208.154 и 128.199.248.105;

• Dyn — сторонний DNS-сервер, который обеспечивает оптимальность работы в Интернете и защищает информацию от большинства фишинговых атак. Настройка сервера Dyn выполняется по IP-адресам 216.146.35.35 и 216.146.36.36;
• SafeDNS — облачный DNS — сервер, позволяющий просматривать любые веб-страницы безопасно для компьютера. Чтобы его использовать, применяют адреса 195.46.39.39 и 195.46.39.40
• DNS.Watch — бесплатная общедоступная служба DNS, которая обеспечивает быстрый, надежный и безопасный просмотр веб-сайтов. Для настройки ПК или маршрутизатора с помощью DNS.Watch, используйте два IP-адреса DNS: 84.200.69.80 и 84.200.70.40.

Настраиваем DNS. Какую Windows лучше использовать

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

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

Настройка DNS на компьютерах с операционными системами Windows 10, 8.1, 8, 7, Vista и XP имеет свою специфику, которую стоит рассмотреть более подробно.

Настройка DNS в Windows 10, 8.1, 8 будет включать этапы:

• нажатие сочетание клавиш Windows + R, ввод в окне «Выполнить» команды control.exe /name Microsoft.NetworkandSharingCenter и нажатие ОК для открытия Центра управления сетями и общим доступом (также это можно сделать в меню Панель управления > Сеть и Интернет);
• выбор пункта Сеть для подключения в  разделе Просмотр основных сведений о сети и настройка подключений, выбор пункта Свойства в открывшемся окне;
• выбор пункта «IP версии 4 (TCP/IPv4) в Windows 10» или «Протокол Интернета версии 4 (TCP/IP)» в окне свойств подключения в списке «Отмеченные компоненты используются этим подключением» и нажатие кнопки Свойства;
• выбор пункта «Использовать следующие адреса DNS-серверов» в открывшемся окне на вкладке Общие.
• ввод выбранных вами адресов DNS в поля Предпочитаемый DNS-сервер и Альтернативный DNS-сервер (в зависимости от выбранного сервиса поле может оставаться пустым);
• подтверждение параметров при выходе и сохранение изменений. 

Обновление DNS-кэша выполняется следующим образом: после нажатия правой кнопкой мыши по значку Windows (меню Пуск) и выбора Командная строка (администратор) или Windows PowerShell (администратор) вводится команда ipconfig /flushdns, после чего нажимается Enter (Ввод) и проводится перезагрузка компьютера.

Настройка DNS в Windows 7 предполагает:

• нажатие правой кнопкой мыши на значок интернета в трее, выбор Центра управления сетями и общим доступом;
• выбор в разделе Просмотр активных сетей пункта справа от Подключения;
• нажатие кнопки Свойства на вкладке Общие в окне Состояние Подключения;
• выбор «Протокол Интернета версии 4 (TCP/IPv4)» на вкладке Сеть окна свойства подключения, нажатие кнопки Свойства;
• выбор на вкладке «Общие» окна Свойства пункта «Использовать следующие адреса DNS-серверов», а затем — ввод IP-адреса выбранного DNS-сервиса;
• подтверждение и сохранение параметров при выходе.

Для Windows 7 кэш обновляется следующим образом: нажатие меню Пуск ввод cmd в поле «Найти программы и файлы» нажатие правой кнопкой мыши по найденной ссылке и выбор Запустить от администратора. В Командной строке — ввод команды ipconfig /flushdns и нажатие клавиши Enter (Ввод). После этого компьютер перезагружается.

Настройка DNS в Windows XP состоит в следующем:

• в меню Пуск открывается Панель управления;
• в окне Панель управления выбираются Сетевые подключения, затем выбирается текущее подключение;
• на вкладке «Общие» в окне Состояние подключения нажимается кнопка Свойства;
• на вкладке «Общие» окна Свойства подключения выбирается Протокол Интернета (TCP/IP), затем нажимаются Свойства;
• на вкладке «Общие» окна Свойства Протокол Интернета (TCP/IP), в нижней части, выбирается Использовать следующие адреса DNS-серверов, а затем вводится IP-адрес выбранного DNS-сервиса
• нажмите кнопка ОК и закрываются все окна.

Настройка DNS в Windows Vista включает этапы:

• в меню Пуск открывается Панель управления;
• в окне Панель управления выбирается Центр управления сетями и общим доступом;
• в разделе Сеть выбирается Просмотр состояния каждого соединения;
• на вкладке Общие в окне Состояние подключения нажимается кнопка Свойства;
• на вкладке Сеть свойства подключения выбирается Протокол Интернета версии 4 (TCP/IPv4) и нажимается кнопка Свойства;
• на вкладке «Общие» окна Свойства выбирается Использовать следующие адреса DNS-серверов, а затем вводится IP-адрес выбранного DNS-сервиса;
• нажимается кнопка ОК и закрываются все окна.

В настоящее время первоначальный стандарт IP-адресов — протокол IPv4, который допускает только до 4,3 миллиарда IP-адресов — заменяется на протокол IPv6, который поддерживает до 3.4×1038 IP-адресов. DNS-серверы все чаще возвращают IP-адреса в формате IPv6, однако могут полностью поддерживать как IPv4-адреса, так и IPv6-адреса при использовании на ОС Windows Server 2008.

Какое оборудование подойдет для DNS сервера

DNS не самая требовательная служба, по-этому достаточно оборудования в базовой конфигурации. С данной ролью хорошо спрявятся такие серверы как HPE Proliant DL360 Gen9,Dell R630 и им подобные, простые, недорогие и надежные. Также для крупных компаний с количеством пользователей более 100, мы рекомендуем настроить несколько DNS-серверов, тем самым обеспечив отказоустойчивать. Еще один фактор для выбора сервера — это в какой среде будет разовачивается DNS-сервер, в виртуальной или на отдельностоящей машине.

Подобрать оборудование для DNS-сервера помогут наши специалисты.

Что такое 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, познакомились с основными типами записей и в картинках показали как эти записи делаются. А если все вышеописанное показалось Вам трудным, то наши специалисты настроят Вам сервер менее, чем за час.

Привет.

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) – напишем отдельно. Удач!