Dns сервер windows: 404 — Содержимое не найдено

Содержание

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

Привет.

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

Дата последнего редактирования текста: 2015-01-04T14:11:58+08:00

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

DNS-сервер в Windows Server 2012-2016 » Блог Андрея Бондаренко

Приветствую Вас, уважаемые читатели. Сегодня у нас тема: «DNS-сервер в Windows Server 2012-2016». И опять две ОС в одной статье. Статья о добавлении роли DNS-сервера, и создании зон просмотра.

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

Установка DNS-сервера в Windows Server 2012-2016

Подготовительные действия

Так же как и в статье о Windows Server 2008, убеждаемся, что сетевой адаптер у Вас настроен должным образом. (Ip адресс, маска подсети, основной шлюз, DNS-сервера)

  • В свойствах системы, заходим в «Изменить параметры», и в открывшемся окне жмём на «Изменить».
  • В следующем окне, даём имя серверу (на Ваше усмотрение), и жмём на «Дополнительно».

Открывается следующее окно.

  • Прописываем основной DNS-суффикс компьютера.(Имя домена Вашей сети)
  • Жмём «ОК».
  • В окне, изменения имени компьютера, так же жмём «ОК».

Выходит сообщение, о необходимости перезагрузить компьютер.

  • Перезагружаем компьютер.
Добавление роли DNS-сервера
  • После загрузки системы, открываем диспетчер сервера, и заходим в «Добавить роли и компоненты».
  • Жмём «Далее», в окне памятке мастера.
  • В окне, типа установки, нас интересует «Установка ролей и компонентов».
  • Жмём «Далее».

В следующем окне нам нужно выбрать целевой сервер.

  • Выбираем нужный сервер или виртуальный диск.
  • Жмём «Далее».

Следующий шаг, это выбор ролей сервера.

  • Выбираем DNS-сервер.
  • Появляется окно с компонентами, необходимыми для функционала данной роли.
  • Жмём «Добавить компоненты».
  • И в окне, выбора ролей, жмём «Далее».

В следующем окне, можно выбрать дополнительные компоненты.

  • Если что то нужно, выбираем.
  • Жмём «Далее».

Окно с информацией о DNS-сервере.

  • Выходит сводка, устанавливаемых компонентов.
  • Если ничего не забыли, то жмём «Установить».
  • Ждём окончания установки.
  • По окончании, жмём «Закрыть».
Настройка DNS-сервера
  • Заходим в диспетчер сервера, в списке выбираем «DNS».
  • В панели мониторинга появляется наш сервер, кликаем по нему правой кнопкой мышки, и выбираем «Диспетчер DNS».
  • Открывается оснастка, выбираем наш сервер, кликаем правой кнопкой мышки, и выбираем «Настроить DNS-сервер».
  • Открывается мастер.
  • Жмём «Далее».

Открывается окно выбора действия.

  • Выбираем «Создание зон прямого и обратного просмотра».
  • Жмём «Далее».
  • В следующем окне, выбираем «Да, создать зону прямого просмотра».
  • Жмём «Далее».

Следующее окно, это выбор типа зоны.

  • Выбираем «Основная».
  • Жмём «Далее».
  • Теперь нужно задать имя зоны.
  • Задаём имя, и жмём «Далее».

Следующий шаг, это создание файла зоны.

  • Выбираем «Создать новый», и жмём «Далее».
  • В следующем окне, запрещаем динамические обновления. Мы будем сами обновлять информацию на сервере.
  • Жмём «Далее».
  • Далее нам предлагают создать зону обратного просмотра, ведь мы выбрали это в предыдущих шагах.
  • Выбираем «Да, создать зону обратного просмотра сейчас».
  • Жмём «Далее».
  • В выборе типа зоны, выбираем «Основная».
  • Жмём «Далее».

Далее окно выбора версии протокола, для зоны.

  • Выбираем «Зона обратного просмотра IPv4».
  • В открывшемся окне, указываем идентификатор зоны, и жмём «Далее».

Окно создания файла зоны.

  • Выбираем «Создать новый файл», и жмём «Далее».
  • Так же, как и при создании зоны прямого просмотра, запрещаем динамические обновления.
  • Жмём «Далее».
  • Сервер у нас в сети будет один, так что в следующем окне, выбираем вариант «Нет, не пересылать запросы».
  • Жмём «Далее».
  • Система начинает поиск корневых ссылок.

У нас нет подключения к интернету, поэтому результата не будет.

  • Появляется окно, завершения настройки, жмём «Готово».
  • Выходит сообщение, о неудаче в поиске корневых ссылок.
  • Жмём «ОК».
Проверяем созданные зоны
  • В диспетчере DNS, открываем вкладку «Зоны прямого просмотра», и видим созданную нами зону.
  • Открываем вкладку «Зоны обратного просмотра», и так же видим зону, которую мы создали.

Сегодня мы рассмотрели тему: «DNS-сервер в Windows Server 2012-2016». Добавили роль DNS-сервера, и создали зону прямого, и зону обратного просмотра.

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

С уважением, Андрей Бондаренко.


Видео на тему «DNS-сервер в Windows Server 2012»:

Видео на тему «DNS-сервер в Windows Server 2016»:

Шпаргалка по DNS — blog.bissquit.com

prchecker.info

С сервисом доменных имен уже все знакомы давным давно. Это одна из самых «полезных» служб, назначение которой даже для обычного пользователя более чем очевидно. Мало кто хорошо разбирается в том, как DNS реально работает и что стоит за «простым» разрешением имен из имени в ip-адрес (и не только). Должен признаться, что я и сам понимаю не все нюансы, поскольку по специфике своей работы каждый день с DNS не сталкиваюсь (вписывать серверы DNS в сетевые настройки не считается). Кроме того, даже если удается в чем-то разобраться, все очень быстро забывается. Ведь в корпоративной сети DNS одна их тех служб, которые настроил и забыл.

Давно пришло время сводить полученные знания в какое-то единое место и при необходимости быстро восстанавливать их в голове. Иметь под боком небольшую статью — идеальный вариант. Эта статья будет иметь формат шпаргалки, где я буду формулировать актуальные прежде всего для себя вопросы и с течением времени постепенно на них отвечать.

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

«Согласно руководящим материалам (RFC-1034, RFC-1035) система доменных имен состоит из трех основных частей:

  • Всего множества доменных имен (domain name space)
  • Серверов доменных имен (domain name servers)
  • Клиенты DNS (Resolver-ы)»

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

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

Вообще на этом канале огромное количество уроков, которые посвящены именно DNS. Однозначно советую к просмотру. Хоть и описание типов dns-серверов есть и на Википедии , оно там плоское и только зря сводит с толку.

Вопросов кто такие dns-клиенты возникать не должно.

Если говорить про авторитативные и неавторитативные серверы, то их отличие состоит в том, что в первом случае сервер отвечает за зону, а во втором — нет. То есть неавторитативные серверы выступают в большинстве случаев только как кэширующие и могут только копировать эту зону. Это хорошо понятно из иллюстрации выше.

Есть несколько типов авторитативных dns-серверов: primary master, master, slave. Четкие различия есть только между primary master и slave. Суть в том, что в первом случае сервер стоит во главе иерархии, на нем можно производить изменения описания зоны и этот сервер никогда не будет копировать эту зону с других серверов. Slave-серверы наоборот являются лишь вторичными и копируют зону с primary master; их главная задача — балансировка нагрузки, резервирование. Определение типа серверов master для меня несколько затруднительно. На многих источниках эти серверы также называют основными:

«Описание зоны master-сервера является первичным, т.к. его создает вручную администратор зоны. Соответственно, вносить изменения в описание зоны может только администратор данного сервера. Все остальные серверы только копируют информацию с master-сервера.»

… но, с другой стороны, этому противоречит определение primary-master даже с тех же источников:

«Для того чтобы выделить сервер, который не копирует зоны ни с какого другого сервера, вводят понятие Primary Master.»

То есть по факту не на всех master-серверах можно вносить изменения в описание зоны, а только на одном единственном master-сервере, который называется primary master. В таком случае реально существует только два «статичных» типа сервера — primary master и slave. Роль master может быть у сервера лишь какой-то определенный короткий промежуток времени — когда один slave-сервер (пусть он будет назван Сервер 1) копирует информацию с другого slave-сервера (Сервер 2). В этом случае Сервер 2 имеет право называться master-сервером для Сервер 1, но это справедливо только для конкретно взятого процесса копирования зоны. Когда же Сервер 2 будет копировать описание зоны с единственного primary master, он снова будет являться slave-сервером. Это подтверждает иллюстрация с nic.ru :

Вот таки размышления. Конечно все эти определения скорее запутывают, чем помогают разобраться. Надо просто иметь в виду, что есть primary master и он стоит вверху иерархии и есть все остальные. Стоит добавить, что серверы всех трех типов будут являться авторитативными, то есть ответственными за зону.

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

Прежде чем перейти к описанию типов запросов нужно обратить внимание на ещё один важный момент — разницу между зоной и доменом. Вопрос затрагивается в публикации на Хабре :

Таким образом, пространство имен раздроблено на зоны ( zones), каждая из которых управляется своим доменом. Обратите внимание на различие между зоной (zone) и доменом (domain): домен groucho.edu затрагивает все машины в университете Groucho Marx, в то время как зона groucho.edu включает только хосты, которые работают в непосредственно компьютерном центре, например в отделе математики. Хост в отделе физики принадлежат другой зоне, а именно physics.groucho.edu.

На мой взгляд более точно и понятно сказано в статье на nic.ru, которая упоминалась в самом начале:

Домен — это все множество машин, которые относятся к одному и тому же доменному имени. Например, все машины, которые в своем имени имеют постфикс kiae.su относятся к домену kiae.su. Зона — это «зона ответственности» конкретного сервера доменных имен, т.е. понятие домена шире, чем понятие зоны. Если домен разбивается на поддомены, то у каждого из них может появиться свой сервер. При этом зоной ответственности сервера более высокого уровня будет только та часть описания домена, которая не делегирована другим серверам. Разбиение домена на поддомены и организация сервера для каждого из них называется делегирование прав управления зоной соответствующему серверу доменных имен, или просто делегированием зоны.

Запросы к dns-серверам бывают двух типов — рекурсивный и нерекурсивный (итеративный). Наиболее подробно принцип работы описывается на упомянутом выше канале Youtube. При рекурсивном запросе клиент обращается к предпочитаемому dns-серверу и тот, если не знает ответа, начинает по очереди опрашивать ответственных за зоны серверы, начиная с корневых и далее опускаясь ниже по иерархии. Исчерпывающее объяснение работы рекурсивного запроса дается в статье на oszone.ru. Итеративный запрос менее распространен. В нем клиент сам по очереди опрашивает dns-серверы, начиная с корневых и т.д.. Разумеется если не найдет результаты запроса в своем кэше.

Наглядно рекурсивный запрос выглядит так:

а нерекурсивный :

На этом обзор основных принципов работы dns закончен. Рассмотрение типов записей dns, а также механизмов работы обратного разрешения имен (ip-адрес по dns-имени) я в рамках этой статьи я затрагивать не планировал, хотя конечно же это очень интересные темы.

Настройка роли dns на Windows Server представляет из себя достаточно простую задачу, как и многие другие — добавил роль в диспетчере сервера, запустил визарда и все настроил. Тем не менее встречаются парадоксальные ситуации и иногда слышишь рассказы как некоторые «админы» добавляют одни и те же учетные записи пользователей по очереди на каждом контроллере домена, не имея понятия о репликации. И ведь самое страшное, что у них это получается! То есть можно сделать вывод, что контроллеры домена хоть и поддерживают один и тот же домен, но фактически друг о друге ничего не знают (иначе учетку с аналогичным именем создать бы не получилось). А ведь это может являться следствием неправильной настройки роли DNS, которая обычно всегда идет бок о бок с AD DS.

Этот раздел будет посвящен обзору лучших практик по настройке роли DNS (интегрированной в AD) на Windows Server 2012 R2, но большинство советов актуальны и для предыдущих версий ОС. Тем не менее не стоит забывать про улучшения, которые добавляются в каждой новой версии и 2012 R2 не исключение .

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

Собственно сами рекомендации:

1) «If multiple DCs are configured as DNS servers, they should be configured to use each other for resolution first and themselves second» .

Суть в том, что, во избежание проблем с репликацией, в списке первичных dns-серверов на каждом контроллере домена первыми должны быть указаны партнеры по репликации, то есть другие контроллеры домена. Собственный адрес отдельно взятого сервера должен быть указан самым последним в его списке dns-серверов. Для увеличения производительности последним в списке используйте loopback-адрес 127.0.0.1  как собственный адрес сервера (но не реальный сетевой адрес адаптера), хоть и это иногда может вызывать небольшие проблемы .

2) На клиентских системах должны использоваться только локальные dns-серверы, но никак не публичные.

В противном случае у вас могут возникнуть проблемы с разрешением внутренних имен, хотя выход наружу будет доступен. Тем не менее в корпоративной сети у меня доступ наружу по dns портам разрешен только контроллерам домена и серверам Exchange.

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

3) Если у вас домен AD, то используйте только интегрированную с AD роль DNS (AD-integrated). Прибавится достаточно много плюсов в плане безопасности, производительности и отказоустойчивости .

Если говорить про отказоустойчивость, то у вас не будет единой точки отказа в виде одного primary master-сервера для вашей зоны dns (если этот сервер выйдет из строя и не будет сразу восстановлен или заменен, запросы клиентов на изменение записей обрабатываться не будут. Не то что бы это очень большая проблема для статичного парка пк, но приятного мало). К тому же администраторам не придется возиться с двумя разными схемами репликации — dns и ad ds; у более простых и понятных схем надежность возрастает в разы.

Производительность всей инфраструктуры увеличивается, поскольку все партнеры по репликации (контроллеры домена) имеют одинаковый вес и нет master- и slave- серверов. То есть, если бы запрос поступил к slave-серверу классического dns, то он должен был бы обратиться к мастеру для инициирования процесса обновления. При интегрированной в ad dns каждый контроллер домена может писать изменения в базу dns и уже дальше неспеша реплицировать их на другие контроллеры. К тому же сам по себе механизм репликации ad ds значительно быстрее.

Безопасность увеличивается благодаря защищенным динамическим обновлениям . О DNSSEC речь тут не идет, это общая технология, хотя и в Windows есть её реализация .

Из лучших практик это наверно все. Есть некоторые размышления касательно того, что лучше использовать — корневые подсказки или серверы пересылки, но это скорее личное дело админа, чем какая-то устоявшаяся практика. Помните, что к корневым серверам ваш dns-сервер выполняет итеративные запросы, а к серверам пересылки — рекурсивные, являясь по отношению к ним клиентом. Root hints сконфигурированы изначально, т.к. они едины для всей сети интернет, а forwarder’ы придется указать вручную. Единственное, что можно отметить — не указывайте в серверах пересылки публичные серверы; пусть лучше это будут dns-ресурсы вашего провайдера.

Есть также рекомендации (обязательно к прочтению) касательно автоматической очистке записей dns. В этой статье я их подробно не рассматриваю, поскольку автоматическая очистка записей по умолчанию отключена. На деле процесс настройки очень простой, но имеет колоссальные последствия для инфраструктуры в том случае, если вы не понимаете что конкретно делаете и к чему это может привести.

comments powered by HyperComments

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

Всем привет Поговорим о DNS, а вернее о том, как его установить в Windows XP. Но для чего нужен этот DNS? Значит DNS, это такой сервер, который сообщает вашему компьютеру, какой сайт под каким IP работает. Вы может быть просто не знаете, но то, как мы видим имя сайта, то это сделано исключительно для нашего удобства. А на самом деле каждый сайт, это набор цифр и точек, ну то есть адрес сервера на котором он расположен.

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

Я лично рекомендую поставить DNS от Google, ибо они стабильные и работающие. В принципе мне сложно представить, чтобы они не работали. Я покажу как установить DNS на Windows XP, тут нет ничего сложного. Значит смотрите, нажимаете Пуск и выбираете там пункт Панель управления:

РЕКЛАМА

Теперь вам нужно найти значок Сетевые подключения:

РЕКЛАМА

В папке Сетевые подключения у вас будет подключение к интернету. Но это может быть как отдельное подключение к интернету, так и просто сетевая карта (адаптер). В общем если у вас есть подключение в виде названия вашего провайдера, ну или просто написано Интернет, или Мобильный интернет, ну короче какое-то название, которое точно говорит о том что это именно интернет, то нажимаете по нему правой кнопкой и выбираете Свойства. В случае если у вас просто одно подключение и больше ничего нет, тогда нажимаете по нему правой кнопкой и выбираете Свойства. Вообще под подключением я имею ввиду вот это:

Вот то что на картинке выше, это просто подключение по локальной сети, оно одно, и поэтому DNS-сервер нужно задавать именно в нем! Вот пример отдельного подключение к интернету (вы в нем например еще можете вводить логин и пароль):

РЕКЛАМА

Главное в этом всем деле, это правильно выбрать интернетовское подключение так бы сказать! В общем я надеюсь, что у вас получится правильно выбрать такое подключение. Но в любом случае я покажу как задать DNS как для интернетовского подключения, так и просто для сетевой карты. Начнем с первого, нажимаем правой кнопкой и выбираем Свойства:

РЕКЛАМА

Теперь идем на вкладку Сеть (вам может и не нужно будет идти на эту вкладку) и там выбираем Протокол Интернета (TCP/IP) и нажимаем кнопку Свойства:

Теперь вам нужно выбрать Использовать следующие адреса DNS-серверов и указать сами сервера:

РЕКЛАМА

Потом нажимаем ОК и потом в предыдущем окне тоже жмем ОК. Все, теперь у вас стоят DNS-сервера от Google!

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

Здесь также выбираем Протокол Интернета (TCP/IP) и нажимаем кнопку Свойства:

РЕКЛАМА

Ну и теперь тут таким же образом вы прописываете DNS-сервера:

Потом нажимаете ОК в этом окне и в предыдущем.

Вот и все, теперь у вас стоят DNS от Google и думаю что с этой инструкцией у вас точно не будет сложностей

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

8.8.8.8
8.8.4.4

Но есть и другие сервера, вот например от OpenDNS:

208.67.222.222 (resolver1.opendns.com)
208.67.220.220 (resolver2.opendns.com)

И есть DNS даже от Яндекса, которые разделяются по зонам. Вот базовые DNS-сервера:

77.88.8.8
77.88.8.1

Вот безопасные (без вирусов и мошеннических сайтов):

77.88.8.88
77.88.8.2

А вот семейные (без сайтов для взрослых):

77.88.8.7
77.88.8.3

Так что можете выбрать тот, который больше удобен

Ну вот ребята на этом и все, надеюсь что все вам тут было понятно. Удачи вам и хорошего настроения

На главную! DNS Windows XP 17.09.2016

Установка и настройка DNS

Установка и настройка DNS

Хотя существует несколько различных способов для установки и конфигурирования DNS, наиболее простой и полный из них подразумевает вызов сначала мастера добавле­ния ролей (Add Roles Wizard), а затем — мастера настройки сервера DNS (Configure a DNS Server Wizard).

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

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

  1. Откройте консоль Server Manager (Диспетчер сервера).
  2. Выделите узел Roles (Роли) и щелкните на ссылке Add Roles (Добавить роли).
  3. На странице Before You Begin (Прежде чем приступить к работе) ознакомьтесь с ото­бражаемыми сведениями и щелкните на кнопке Next (Далее).
  4. Отметьте флажок рядом с ролью DNS Server (Сервер DNS) и щелкните на кнопке Next (Далее).
  5. На странице Introduction to DNS Server (Вводные сведения о DNS-сервере) щелкните на кнопке Next.
  6. На странице Confirmation (Подтверждение) щелкните на кнопке Install (Установить), чтобы запустить процесс установки роли DNS-сервера.
  7. По завершении процесса установки щелкните на кнопке Close (Закрыть), чтобы выйти из мастера добавления ролей (Add Roles Wizard).

Настройка DNS сервера


После выполнения этих шагов роль DNS Server (DNS-сервер) будет установлена на ком­пьютере с Windows Server 2008 R2, но не сконфигурирована. Далее описаны шаги, необхо­димые для ее настройки.

  1. Откройте консоль Server Manager (Диспетчер сервера).
  2. Разверните последовательно узлы Roles (Роли), DNS Server (DNS-сервер) и DNS, по­сле чего щелкните на имени сервера DNS.
  3. В меню Action (Действие) выберите пункт Configure a DNS Server (Конфигурация DNS-сервера).
  4. На странице приветствия мастера настройки сервера DNS (Configure a DNS Server Wizard) щелкните на кнопке Next (Далее).
  5. Выберите переключатель Create Forward and Reverse Lookup Zones (Recommended for Large Networks) (Создать зоны прямого и обратного просмотра (рекомендуется для больших сетей)) и щелкните на кнопке Next.
  6. Выберите вариант Yes, Create a Forward Lookup Zone Now (Recommended) (Да, соз­дать зону прямого просмотра сейчас (рекомендуется)) и щелкните на кнопке Next.
  7. Укажите, зону какого типа требуется создать, в данном случае выбрав вариант Primary Zone (Первичная зона), и щелкните на кнопке Next. Если сервер является контрол­лером домена с доступом для записи, для выбора будет также доступен флажок Store Zone in Active Directory (Сохранить зону в Active Directory).
  8. В случае сохранения зоны в Active Directory выберите область репликации и щелкни­те на кнопке Next.
  9. Введите полностью определенное доменное имя зоны (FQDN) в поле Zone Name (Имя зоны) и щелкните на кнопке Next.
  10. На этом этапе в случае создания не интегрируемой с AD зоны можно либо создать новый текстовый файл для зоны, либо импортировать уже существующий. В данном случае выберите вариант Create a New File with This File Name (Создать новый файл с таким именем) и оставьте предлагаемые по умолчанию параметры, после чего для продолжения щелкните на кнопке Next.
  11. На следующей странице будет предложено разрешить или запретить прием дина­мических обновлений сервером DNS. В рассматриваемом примере разрешите DNS-серверу принимать динамические обновления, выбрав переключатель Allow Both Nonsecure and Secure Updates (Разрешать как безопасные, так небезопасные обнов­ления), и щелкните на кнопке Next.
  12. На следующей странице предлагается создать зону обратного просмотра. В данном случае выберите переключатель Yes, Create a Reverse Lookup Zone Now (Да, создать зону обратного просмотра сейчас) и щелкните на кнопке Next.
  13. Укажите, что зона обратного просмотра должна представлять собой первичную зону, выбрав перелючатель Primary Zone (Первичная зона), и щелкните на кнопке Next.
  14. В случае сохранения этой зоны в Active Directory выберите область репликации и щелкните на кнопке Next.
  15. Оставьте выбранным предлагаемый по умолчанию вариант IPv4 Reverse Lookup Zone (Зона обратного просмотра IPv4) и щелкните на кнопке Next.
  16. Введите идентификатор сети для зоны обратного просмотра и щелкните на кноп­ке Next. (Как правило, в качестве сетевого идентификатора вводится первый набор октетов из IP-адреса зоны. Например, если в сети используется диапазон IP-адресов класса С 192.168.3.0/24, то в качестве сетевого идентификатора могут быть введено значение 192.168.3.
  17. В случае создания не интегрируемой с AD зоны будет снова предложено либо создать новый файл для зоны, либо импортировать уже существующий. В рассматриваемом примере выберите переключатель Create a New File with This File Name (Создать но­вый файл с таким именем) и щелкните на кнопке Next.
  18. После этого появится приглашение указать, должны ли быть разрешены динами­ческие обновления. Для целей этого примера выберите переключатель Allow Both Nonsecure and Secure Updates (Разрешать как безопасные, так и небезопасные об­новления) и щелкните на кнопке Next.
  19. На следующей странице будет предложено настроить параметры ретрансляторов, о которых более подробно речь пойдет в разделе «Зоны DNS» далее в главе. В рассмат­риваемом примере выберите переключатель No, It Should Not Forward Queries (Нет, не следует переадресовывать запросы) и щелкните на кнопке Next.
  20. На последнем экране будут представлены сводные сведения о выбранных для внесе­ния и добавления в базу данных DNS изменениях и зонах. Щелкните на кнопке Finish (Готово), чтобы внести все эти изменения и создать нужные зоны.

DNS-сервер на Windows 7: запуск, настройка и устранение возможных ошибок

Декабрь 12th, 2016 Марина Кардополова

Иногда пользователям требуется самостоятельно установить и настроить DNS-сервер на операционной системе Windows 7. Он может применяться в рабочих целях, для создания собственного сайта или по любым другим причинам. Windows 7 — это графическая операционная система (в отличие от Linux), интерфейс которой интуитивно понятен, и настроить DNS-сервер не составит большого труда даже для человека, не обладающего специальными навыками. Аналогично можно своими руками исправить возникающие ошибки, когда ДНС не отвечает, недоступен или не обнаружен.

Что такое DNS-сервер и для чего он нужен

DNS — это не что иное, как Domain Name System. Как следует из названия, это сервер, который выдаёт доменные имена IP-адресам в интернете. Все сайты имеют свой IP, другими словами, набор цифр, который позволяет компьютеру добраться до интернет-ресурсов (например, 192.168.11.231). Но при смене провайдера адрес меняется, как же пользователям узнать, где теперь находится их веб-портал? Для этого и нужен DNS-сервер, он выдаёт понятные человеку наименования вместо IP и позволяет вам достучаться до нужного адреса без знания набора цифр.

Итак, в один прекрасный момент вы решили, что вам нужно доменное имя для почты, личного сайта или FTP-сервера. Вам нужно будет установить и настроить ДНС-сервер, чтобы ваш хост смогли найти без сложного запоминания набора цифр.

Где найти и как включить ДНС на Windows 7

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

  1. В меню «Пуск» вам первым делом понадобится зайти в «Панель управления».

    Выберите «Панель управления»

  2. Если панель управления имеет сокращённый вид, то в пункте «Сеть и интернет» обратите внимание на «Просмотр состояния сети и задач». Если у вас по умолчанию отображаются все элементы панели управления единым списком, используйте «Центр управления сетями и общим доступом».

    Выберите «Просмотр состояния сети и задач»

  3. В разделе «Просмотр активных сетей» найдите то подключение, благодаря которому вы имеете доступ к интернету (то, что стоит после «Подключения»), и нажмите на него.

    Выберите подключение для

  4. Перед вами откроется новое окно, в котором отображаются все настройки выбранного подключения. Нажмите кнопку «Свойства».

    Нажмите кнопку «Свойства»

  5. Среди отмеченных компонентов, которые используются подключением, найдите «Протокол Интернета версии 4 (TCP/IPv4)» или «Протокол Интернета версии 6 (TCP/IPv6)» и щёлкните по кнопке «Свойства».

    Выберите «Свойства» для подходящего протокола

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

    Введите адрес вашего сервера и альтернативного

  7. После этого не забудьте нажать «Ок», чтобы ваши изменения сохранились.

Когда возникает необходимость менять

Обычно все пользуются DNS-сервером своего провайдера, но он не всегда обеспечивает хорошую скорость загрузки. К тому же такие механизмы часто не справляются с нагрузкой и «падают», тем самым ограничивая вам доступ во всемирную сеть. Такие бесплатные сервисы, как Яндекс.DNS или Google Public DNS помогут обойти эту проблему.

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

В связи со введением новых законов в Российской Федерации провайдеры обязаны блокировать доступ к некоторым сайтам. Многим уже известны пути обхода этого ограничения, и один из них — это DNS-сервер. Закон не коснулся компаний, предоставляющих услуги по подключению ДНС, а это значит, что у них есть ещё одно преимущество перед провайдерами.

Как настроить или изменить

  1. Проделайте пункты 1–5 включения DNS.
  2. Вместо ввода IP-адресов (которые уже есть) нажмите на кнопку «Дополнительно».

    Нажмите на кнопку «Дополнительно»

  3. В новом открывшемся окне «Дополнительные параметры TCP/IP» перейдите на вкладку DNS.

    Перейдите на вкладку DNS и измените настройки сервера

  4. Измените настройки и нажмите «Ок», чтобы сохранить их.

На одном из этапов вы вводили адрес сервера и альтернативный. Это нужно потому, что доменные имена со всего мира не могут храниться в одном месте. Когда компьютер ищет среди DNS запрашиваемое имя, он обходит несколько серверов по порядку, который вы можете самостоятельно задать в текстовом поле «Адреса DNS-серверов в порядке использования». Здесь может быть не только два набора цифр, введённых изначально, но и несколько дополнительных.

DNS-суффиксы нужны для формирования внутренних сетей, поддоменных имён (например, subdomain.domain.com). Если сервер вам необходим только для подключения к интернету, то можно пропустить эту настройку и оставить её по умолчанию. Если вы пользуетесь, например, внутренней рабочей сетью, введите суффиксы её поддоменов в соответствующее поле.

Включённая настройка «Зарегистрировать адрес этого подключения в DNS» означает, что ваш компьютер будет зарегистрирован на сервере со своим адресом и именем устройства, прописанного в настройках. Узнать, как называется ваше устройство, можно в «Панели управления» в пункте «Система». Включённый пункт «Использовать DNS-суффикс подключения при регистрации в DNS» присоединит к имени вашего компьютера в сети дополнительный суффикс.

Как поменять DNS-сервер: необходимые настройки на видео

В каких случаях DNS может не отвечать и что надо делать

Служба DNS отключена

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

  1. В меню «Пуск» найдите «Панель управления».
  2. Выберите «Система и безопасность».

    Выберите «Система и безопасность»

  3. В следующем окне нажмите на «Администрирование».

    Нажмите на «Администрирование»

  4. Перед вами откроется список всех доступных программ, выберите «Службы».

    Выберите «Службы»

  5. Найдите «DNS-клиент» и дважды щёлкните по нему мышкой.

    Кликните на DNS-клиент

  6. Обратите внимание на «Тип запуска» — этот пункт должен иметь настройку «Автоматически».

    DNS должен запускаться автоматически

  7. После изменения не забудьте сохранить, нажав «Ок».

Неисправность DNS-сервера

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

Как исправить возможные ошибки сервера ДНС: видео

Что такое DHCP-сервер и чем он отличается от DNS

Во время настройки DNS-сервера вы часто сталкивались с аббревиатурой DHCP. Что это и для чего нужно?

DHCP расшифровывается как Dynamic Host Configuration Protocol. Это сетевой протокол, который автоматически выдаёт компьютерам в сети нужные IP-адреса и другие настройки. Например, администратор сети может задать диапазон, в котором должны находиться хосты. Это значительно ускоряет настройку большой компьютерной сети и позволяет избежать множества ошибок.

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

DNS-сервер нужен для хранения доменных имён различных IP-адресов в интернете. Его использование имеет множество преимуществ: ускорение загрузки, гибкие настройки, обход блокировки ресурсов. Наладить его работу в операционной системе Windows 7 вовсе не сложно. А практически любая проблема с подключением решается включением службы или сменой сервера.

Начинающий копирайтер и переводчик. Оцените статью: Поделитесь с друзьями!

Устраняем проблемы DNS | Windows IT Pro/RE

Работа с DNS — важнейшая часть планирования Active Directory (AD). Прежде чем организовать домен AD, необходимо установить DNS. Служба AD и создающая для нее основу служба DNS требуют более тщательного планирования, чем любой другой инструмент Microsoft. Действовать по принципу «сначала щелкни, а там видно будет» — верный способ навлечь на себя неприятности. Однако из-за ряда особенностей AD настроить DNS для работы с AD нелегко даже опытным администраторам, хорошо знакомым с DNS. В данной статье рассматриваются принципиальные условия, которые необходимо соблюдать при настройке DNS для работы с AD, а также полезные новые функции DNS, реализованные в Windows Server 2003.

Прежде чем создавать домен AD, требуется установить один или несколько DNS-серверов для размещения DNS-зоны с тем же именем. Следует обратить внимание на термины «домен» и «зона». Термин «домен» может иметь два значения. Можно говорить о DNS-домене с именем bigfirm.biz в смысле, не имеющем ничего общего с AD и любыми программами Microsoft. Но можно говорить об AD-домене с именем bigfirm.biz — такой домен не имеет большого отношения к DNS, зато тесно связан с безопасностью в программных системах Microsoft. Чтобы не путать DNS-домены с AD-доменами, я буду называть DNS-домен «зоной».

Предположим, что на DNS-сервере компании Bigfirm размещена зона bigfirm.biz. В зону входят Web-сервер и несколько почтовых серверов, и необходимо, чтобы заказчики могли иметь доступ к этим серверам. Но администраторы Bigfirm не хотят использовать данный DNS-сервер и размещенную на внешних машинах зону bigfirm.biz для реализации AD, так как в AD хранится конфиденциальная информация, которую опасно публиковать в Internet. Поэтому, как и большинство проектировщиков AD, администраторы Bigfirm формируют группу DNS-серверов, невидимых из общедоступной сети Internet, на которых размещается зона bigfirm.biz, отделенная от общедоступной зоны bigfirm.biz. Такой подход называется разделением (split-brain или split-horizon) DNS.

Основные сведения о разделенных зонах DNS

Организовать разделенную DNS довольно просто, и я рассказывал об этом в других статьях. Напомню коротко, что для организации разделенной DNS сначала нужно установить серверную службу DNS на нескольких серверах. Затем компании Bigfirm следует настроить конфигурацию каждой системы во внутренней сети (то есть сети, в которой необходимо отыскивать контроллеры домена AD), чтобы они могли получать информацию DNS от одного или нескольких внутренних серверов. Клиенты DNS внутри корпоративной сети никогда не должны запрашивать DNS-серверы в общедоступной Internet; в противном случае они никогда не смогут обнаружить контроллеров домена (DC). То же справедливо и для внутренних DNS-серверов: их следует настроить на преобразование имен только с использованием внутренних DNS-серверов. Хотя внутренние DNS-серверы обращаются друг к другу для преобразования имен, они могут преобразовывать имена Internet.

Bigfirm может назначить один из внутренних DNS-серверов первичным DNS-сервером для внутренней зоны bigfirm.biz и разрешить динамическое обновление этой зоны. Затем можно настроить все остальные DNS-серверы сети для работы в качестве вторичных DNS-серверов зоны bigfirm.biz; каждый из них получает экземпляры зоны bigfirm.biz с первичного сервера bigfirm.biz. Такой простой подход позволяет разместить разделенную DNS для одного домена AD.

Добавление зон, интегрированных с AD

Приведенное описание — недостаточно полное для многих администраторов, так как оно не охватывает зоны, интегрированные с AD. Использование первичных и вторичных DNS-серверов для данной зоны — стандартный способ применения DNS-серверов. Впервые этот метод был использован в широко распространенной серверной программе BIND DNS; аналогичный способ применяется и во встроенных DNS-серверах Windows 2000 Server и Windows 2003. Эта модель предусматривает наличие в зоне одного первичного сервера DNS и неограниченного числа вторичных. Любые изменения в зоне должны производиться на первичном DNS-сервере, который затем копирует измененные параметры на вторичные серверы. В терминах Windows 2000 этот подход можно назвать моделью с одним мастером, так как принимать изменения может только один ответственный за зону DNS сервер.

Модель с одним мастером — слабое звено архитектуры с первичным и вторичными DNS-серверами. В Windows 2003, Windows XP и 2000 используется динамическая служба DNS (DDNS), поэтому каждая рабочая станция и сервер должны перерегистрировать свои имя и адрес в зоне DNS каждый день в процессе начальной загрузки (это упрощенное представление: на самом деле процедуру перерегистрации запускают пять различных событий). В модели первичный/вторичный только первичный DNS-сервер зоны может принимать изменения для этой зоны. Если компания располагает несколькими тысячами машин, то в течение считанных минут после начала рабочего дня на первичный DNS-сервер могут обрушиться тысячи запросов на DNS-регистрацию.

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

Кроме того, интеграция зоны DNS с AD повышает безопасность сети, так как регистрацию DDNS могут выполнить только члены домена. В простой первичной зоне DNS, принимающей динамическую регистрацию, любая машина может регистрировать DNS-записи. Поэтому теоретически любая посторонняя машина может регистрировать записи, выдавая себя за DC. Сам факт появления системы, выдающей себя за DC, не приведет к нарушению информационной безопасности сети, но такое положение нельзя считать нормальным — за этим может скрываться попытка кражи паролей. Однако в зоне, интегрированной с AD, посторонней машине гораздо труднее присвоить чужую роль. Прежде чем принять регистрацию DNS, интегрированные с AD серверы DNS проверяют, является ли регистрируемая машина членом домена.

Островная DNS

Зоны, интегрированные с AD, и разделенная DNS могут породить конфликт, известный под названием «островная DNS» (island DNS). В случае с островной DNS два или несколько DC выполняют роль DNS-серверов домена, и на них, как обычно, размещается зона, интегрированная с AD. Но каждый DC располагает своей информацией. Каждый DC регистрирует идентификационную информацию о своем экземпляре зоны DNS, но никогда не реплицирует эту информацию на другие DC/DNS-серверы (то есть серверы, которые играют двойную роль DC и DNS-серверов). Поэтому каждый DC/DNS-сервер считает себя единственным на планете.

Островная DNS возникает только в корневом домене леса, только если используются зоны, интегрированные с AD, применяется разделенная DNS (каждый DNS-сервер настроен на разрешение запросов DNS лишь у себя) и только если в корневом домене имеется более одного DC/DNS-сервера. Насколько мне известно, возникновение островной DNS возможно в DNS-серверах на базе Windows 2003 и Windows 2000.

Чтобы избежать появления островной DNS, следует изменить конфигурацию DC/DNS-сервера. Во-первых, нужно назначить одну систему DC/DNS «ведущим» DNS-сервером зоны. Этот сервер не будет настоящим мастером. Регистрацию DNS по-прежнему станут выполнять несколько мастеров, но я пользуюсь этим термином для простоты изложения. Ведущий DNS-сервер должен по-прежнему указывать на себя (поле Preferred DNS server в окне TCP/IP Properties этой системы должно содержать только собственный IP-адрес данного сервера). Поле Alternate DNS server остается пустым. Затем нужно настроить другие DNS-серверы таким образом, чтобы они использовали IP-адрес мастера в качестве основного DNS-сервера, а какой-нибудь другой DNS-сервер — в качестве альтернативного. За исключением мастер-сервера, никогда не следует настраивать систему на обращение к самой себе как основной или альтернативной.

Предположим, у нас имеется три контроллера с именами DC1, DC2 и DC3. Все три DC являются DNS-серверами, расположены в корневом домене леса и хранят информацию о зоне DNS данного домена в интегрированной с AD зоне. Произвольно назначив DC1 ведущим, я настроил DC1 таким образом, чтобы в его поле Preferred DNS server содержался IP-адрес DC1, и оставил поле Alternate DNS server пустым. Я вставил IP-адрес DC1 в поле Preferred DNS server контроллера DC2, а в поле Alternate DNS server контроллера DC2 указал IP-адрес DC3. В поле Preferred DNS server контроллера DC3 я ввел IP-адрес DC1, а в поле Alternate DNS server контроллера DC3 — IP-адрес DC2.

Рассмотрим еще два DC (MYDC1 и MYDC2), связи между которыми организованы по тому же принципу. Если произвольно выбрать MYDC1 в качестве мастера, то в поле Preferred DNS server контроллера MYDC1 следует указать IP-адрес MYDC1 и оставить поле Alternate DNS server пустым. В контроллере MYDC2 требуется указать IP-адрес MYDC1 в поле Preferred DNS server. Но что делать с полем Alternate DNS server контроллера MYDC2? Это поле нужно оставить пустым.

Добавление доменов

Предположим, что в bigfirm.biz необходимо иметь два AD-домена — исходный домен bigfirm.biz и домен с именем bigfirm.com. Как в этом случае организовать разделенную DNS? Компании Bigfirm достаточно создать первичную зону с именем bigfirm.com на одном из внутренних DNS-серверов. Все остальные внутренние DNS-серверы компании следует сделать вторичными DNS-серверами зоны bigfirm.com. Таким образом, в распоряжении компании будет вся инфраструктура, необходимая для двухдоменного леса AD.

Если Bigfirm использует зоны, интегрированные с AD, то очевидный следующий шаг — интегрировать с AD как зону bigfirm.biz, так и bigfirm.com и установить DNS на некоторых DC. В результате DNS-серверы каждого домена должны видеть зоны друг друга. Однако данный метод не срабатывает из-за странной особенности зон, интегрированных с AD. Данные о зоне, интегрированной с AD, направляются только на контроллеры домена этой зоны — DC/DNS-серверам bigfirm.com будут видны только данные bigfirm.com. Это ограничение в Windows 2003 можно обойти, но в многодоменные леса на базе Windows 2000 придется внести некоторые изменения, чтобы обеспечить работу DNS, интегрированной с AD. Все DNS-серверы bigfirm.biz необходимо настроить в качестве вторичных DNS-серверов для bigfirm.com, а все DNS-серверы bigfirm.com — в качестве вторичных DNS-серверов для bigfirm.biz. Внутри доменов можно по-прежнему использовать зоны, интегрированные с AD, но в каждом домене должна содержаться вся необходимая информация для обнаружения контроллеров bigfirm.com, и наоборот.

При использовании DNS-серверов на базе Windows 2003 у администраторов Bigfirm будет более широкий выбор. Эти возможности мы рассмотрим в следующей статье.

Марк Минаси — редактоp Windows NT Magazine MCSE и автор книги «Mastering Windows NT Server 4.0» (издательство Sybex). С ним можно связаться по адресу: [email protected]

DNS-сервер Windows

Этот шаблон монитора приложений SAM оценивает состояние и общую работоспособность служб, а также производительность DNS-сервера Microsoft.

Предпосылки

WMI-доступ к целевому серверу.

Учетные данные

Администратор Windows на целевом сервере.

Компонентные мониторы

Нажмите здесь, чтобы просмотреть обзор шаблонов мониторов приложений SAM и мониторов компонентов.Также доступны шаблоны опроса SAM API.

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

Служба: DNS-сервер

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

Память: Кэш-память

Этот монитор компонента возвращает общий объем системной памяти, используемой службой DNS-сервера для кэширования.

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

Память: Память узла базы данных

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

Память: Nbstat Память

Этот монитор компонента возвращает общий объем системной памяти, используемой службой DNS-сервера для Nbtstat.

Память: Запись памяти потока

Этот монитор компонентов возвращает общий объем системной памяти, используемой службой DNS-сервера для потока записей.

Динамическое обновление: NoOperation/сек

Этот монитор компонентов возвращает среднее количество запросов динамического обновления «Нет операций/пустых», полученных DNS-сервером в секунду.

Динамическое обновление: получено

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

Отслеживайте этот счетчик после включения динамических обновлений, чтобы определить, пытаются ли клиенты DNS обновить свои адреса DNS.

Динамическое обновление: отклонено

Этот монитор компонентов возвращает общее количество динамических обновлений, отклоненных DNS-сервером.

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

Динамическое обновление: время ожидания

Этот монитор компонентов возвращает общее количество тайм-аутов динамического обновления DNS-сервера.

Динамическое обновление: запись в базу данных

Этот монитор компонентов возвращает общее количество динамических обновлений, записанных в базу данных DNS-сервером.

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

Рекурсивный: Запросов/сек

Этот монитор компонента возвращает среднее количество рекурсивных запросов, полученных DNS-сервером в секунду.

Рекурсивный: Ошибка запроса/сек

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

Рекурсивный: TimeOut/сек

Этот монитор компонентов возвращает среднее количество тайм-аутов отправки рекурсивных запросов в секунду.

Безопасное обновление: сбой

Этот монитор компонентов возвращает общее количество безопасных обновлений, которые не удалось выполнить на DNS-сервере.

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

Безопасное обновление: получено

Этот монитор компонентов возвращает общее количество запросов на безопасное обновление, полученных DNS-сервером.

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

TCP: Память сообщений

Этот монитор компонентов возвращает общий объем памяти сообщений TCP, используемый DNS-сервером.

TCP: получено запросов/сек

Этот монитор компонента возвращает среднее количество TCP-запросов, полученных DNS-сервером в секунду.

TCP: Ответ отправлен/сек

Этот монитор компонента возвращает среднее количество ответов TCP, отправляемых DNS-сервером в секунду.

Всего полученных запросов/сек

Этот монитор компонента возвращает среднее количество запросов, полученных DNS-сервером в секунду.

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

Всего отправлено ответов/сек

Этот монитор компонентов возвращает среднее количество ответов, отправляемых DNS-сервером в секунду.

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

UDP: Память сообщений

Этот монитор компонентов возвращает общий объем памяти сообщений UDP, используемый DNS-сервером.

UDP: получен запрос/сек

Этот монитор компонента возвращает среднее количество запросов UDP, полученных DNS-сервером в секунду.

UDP: Ответ отправлен/сек

Этот монитор компонентов возвращает среднее количество ответов UDP, отправляемых DNS-сервером в секунду.

Передача зоны: сбой

Этот монитор компонентов возвращает общее количество неудачных передач зон главного DNS-сервера.

Отслеживайте этот счетчик для устранения неполадок при разрешении имен.

Передача Зоны: Успех

Этот монитор компонентов возвращает общее количество успешных передач зон главного DNS-сервера.

Отслеживайте этот счетчик для устранения неполадок при разрешении имен.

Монитор взаимодействия с пользователем DNS

Этот монитор компонентов проверяет способность DNS-сервера отвечать на запрос записи, сравнивает ответ на запрос со списком IP-адресов и измеряет время ответа.Монитор компонентов проходит успешно, если ответ DNS соответствует ожидаемым IP-адресам.

Настройка DNS-сервера в Windows Server 2012 или более поздней версии

DNS (система доменных имен) — это система, позволяющая преобразовывать доменные имена в IP-адреса и наоборот.

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

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

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

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

После того, как машина подключена к обеим сетям, важно помнить, какое соединение необходимо настроить.Обычно сетевой адаптер настраивается по умолчанию с самого начала с выходом в интернет. В то же время другие дополнительные сетевые адаптеры не имеют доступа в Интернет, пока не будет выполнена настройка вручную:

Наведя курсор на значок сети в системном трее, можно найти всплывающую подсказку с краткой информацией о сетях. Следуя приведенному выше примеру, вы можете видеть, что присоединенная сеть — это сеть 3.

Выполнить ряд действий:

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

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

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

Чтобы добавить новые роли в Windows Server, используйте мастер добавления ролей и компонентов в диспетчере серверов.

В верхней панели навигации Диспетчера серверов щелкните меню «Управление» и выберите «Добавить роли и компоненты».

Здесь мастер рекомендует проверить, выполнены ли следующие задачи:

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

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

3. Установлены самые последние обновления безопасности из Центра обновления Windows.

Если вы уверены, что все условия соблюдены, нажмите Далее;

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

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

Отметьте роль DNS-сервера и нажмите Далее:

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

Сохраните список функций как есть и нажмите «Далее»:

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

Еще раз проверьте конфигурацию установки и подтвердите свое решение, нажав Установить:

Последний экран подтверждения сообщает, что установка успешно завершена, и вы можете закрыть мастер установки:

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

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

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

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

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

На верхней панели навигации Диспетчера серверов щелкните меню Инструменты и выберите DNS в раскрывающемся списке:

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

  • Щелкните правой кнопкой мыши папку «Зоны прямого просмотра» и выберите «Новая зона». Откроется мастер создания новой зоны:
  • .
  • На экране приветствия мастера нажмите Далее:
  • На экране «Тип зоны» выберите «Основная зона» и нажмите «Далее»:
  • Введите имя и нажмите Далее:
  • При необходимости измените имя будущего файла зоны и нажмите Далее:
  • Вы должны выбрать, хотите ли вы разрешить динамические обновления или нет.Не рекомендуется допускать этого из-за значительной уязвимости. Нажмите Далее:
  • Убедитесь, что выбраны правильные параметры, нажмите Готово:

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

  • Откройте диспетчер DNS и щелкните правой кнопкой мыши папку «Зоны обратного просмотра», выберите «Новая зона». Откроется мастер создания новой зоны:
  • .
  • На экране «Тип зоны» выберите «Основная зона» и нажмите «Далее»:
  • На первой странице Имя зоны обратного просмотра выберите IPv4, нажмите Далее:
  • Введите идентификатор сети (первые три октета IP-адреса) и нажмите Далее:
  • При необходимости измените имя будущего файла зоны и нажмите Далее:
  • Вы должны выбрать, хотите ли вы разрешить динамические обновления или нет.Не рекомендуется допускать этого из-за значительной уязвимости. Нажмите Далее:
  • Убедитесь, что выбраны правильные параметры, нажмите Готово:

Создание записи узла (A)

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

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

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

Record PTR — это обратная версия A Record.

  • Откройте папку «Зоны прямого просмотра» в диспетчере DNS и найдите папку зоны. Щелкните правой кнопкой мыши в правой части диспетчера DNS и выберите Новый хост (a или AAA):
  • .
  • Открывается новая страница хоста. В поле «Имя» введите имя хоста (без домена будет использоваться имя зоны в качестве домена) и ваш IP-адрес.Отметьте раздел «Создать связанную запись указателя (PTR)», чтобы убедиться, что зоны прямого и обратного просмотра работают правильно:

Если поле Имя пустое, используется имя родительского домена.

  • Вы также можете добавить записи для других серверов:
  • По завершении нажмите Готово.

Проверка правильности

  • Проверить изменения в папках зон (в примере ниже видно, что в каждой из них появилось по 2 записи):
  • Откройте командную строку (cmd) или PowerShell и выполните команду nslookup:

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

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

  • Для запроса домена;
  • Для запроса IP-адреса:

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

  • Есть возможность отправить запрос на внешний ресурс:

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

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

Здесь машина назначила себя DNS-сервером по умолчанию. Доменное имя DNS-сервера отображается как неизвестное, поскольку для IP-адреса (10.0.1.7) нет записей ресурсов. По той же причине 2-й запрос возвращает ошибку (Несуществующий домен).

Описание новых или измененных функций системы доменных имен (DNS) в Windows Server 2016.

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

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

Теперь вы можете использовать эти функции:

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

Конкретное описание этих функций:

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поддержка Windows PowerShell

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

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

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

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

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

Add-DnsServerClientSubnet — этот командлет создает новую подсеть DNS-клиента. Подсети используются политиками DNS для определения местоположения клиента DNS.

Remove-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.

DNS-сервер Powershell
DNS-клиент Powershell

Политики DNS

(Windows) — Men&Mice Docs

Примечание

Управление политиками DNS для DNS-серверов Microsoft доступно только в консоли управления.

Политики DNS и области действия DNS

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

Конкретные типы политик:

Политики передачи зон

Управляет обработкой передачи зон либо для DNS-сервера, либо для конкретной зоны DNS.

Политики рекурсии

Управление тем, как рекурсивные DNS-запросы обрабатываются DNS-сервером.

Политики разрешения запросов

Управляет обработкой запросов для DNS-сервера или определенной зоны.

Динамическое обновление

Управляет обработкой динамических обновлений

Список исключений ограничения скорости

Контролирует настройку ограничения скорости

Политики DNS

используются в сочетании с областями зоны и областями сервера, которые представляют собой новую концепцию, представленную в Windows Server 2016.Область зоны представляет собой конкретную версию существующей зоны, а область сервера — это набор параметров DNS-сервера, связанных с уникальным именем.

Редактировать политики DNS

Редактирование или добавление политик DNS в Windows Server 2016 выполняется

  1. Щелкните правой кнопкой мыши сервер на боковой панели, как показано на рисунке.

  2. Выберите Изменить политики DNS.

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

Определение клиентских подсетей

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

  1. Выберите «Определить клиентские подсети» в подменю «Редактировать политики DNS».

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

  3. Укажите имя подсети и список подсетей в нотации CIDR, которые будут использоваться в правилах исключения.

Добавить области зоны DNS

Чтобы добавить новую область зоны:

  1. Щелкните правой кнопкой мыши зону DNS.

  1. Выберите Добавить область действия после щелчка правой кнопкой мыши по зоне.

  2. Появится новое диалоговое окно, в котором вы можете ввести имя новой зоны zone.

  3. Нажмите кнопку «Добавить», чтобы добавить новую область зоны.

Недавно добавленная область зоны теперь отображается в списке зон.Имя области действия каждой зоны отображается в отдельном столбце.

Редактировать области DNS-сервера

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

  1. Выберите Редактировать области DNS-сервера в подменю Редактировать политики DNS-сервера.

  2. Нажмите кнопку «Добавить», чтобы добавить новую область сервера. Отображается новое диалоговое окно, позволяющее пользователю указать имя новой области сервера.

  3. Нажмите кнопку OK, чтобы добавить новую область сервера.

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

  5. Чтобы изменить параметры области сервера, выделите соответствующую область сервера и нажмите кнопку «Параметры». Отображается новое диалоговое окно, которое позволяет пользователю указать серверы пересылки и выбрать, следует ли разрешить рекурсию. Чтобы отключить использование серверов пересылки для области сервера, оставьте список серверов пересылки пустым.

Примечание

Список серверов пересылки для области сервера по умолчанию по-прежнему можно редактировать в параметрах сервера

Установить ограничение скорости отклика

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

Настройка ограничения скорости

  1. Выберите «Установить ограничение скорости отклика» в подменю «Редактировать политики DNS-сервера»

  2. Чтобы включить ограничение скорости ответа, убедитесь, что установлен флажок «Включить ограничение скорости ответа».

Обзор конфигурации и связанных полей см. ниже.

Включить ограничение скорости отклика

Чтобы включить ограничение скорости отклика

Только журнал

Расчеты RRL выполняются, но потенциальные действия регистрируются, как если бы RRL был включен.

Ответов в секунду

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

Ошибок/секунд

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

Окно обнаружения

Определяет период (в секундах), в течение которого измеряются и усредняются частоты RRL.

Длина префикса IPv4

Указывает длину префикса IPv4, которая указывает размер подсети, в которой группируются входящие запросы.

Длина префикса IPv6

Указывает длину префикса IPv6, которая указывает размер подсети IPv6, в которой группируются входящие запросы

Скорость утечки

Указывает скорость, с которой сервер отвечает на отброшенные запросы

Truncate rate

Указывает скорость, с которой сервер отвечает усеченными ответами

Максимальное количество ответов/окно

Указывает максимальное количество ответов, отправляемых сервером на адрес домена подсети во временном окне RRL.

Список исключений

Позволяет создавать политики, управляющие исключениями RRL.

Добавление исключения

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

Политики DNS

Чтобы добавить политику DNS:

  1. Выберите тип политики DNS в подменю Редактировать политики DNS-сервера.

  2. Нажмите кнопку «Добавить», чтобы добавить новую политику

  3. Отображается новое диалоговое окно.Это стандартное окно для добавления политики DNS. Дополнительные сведения см. в разделе Добавление политик DNS.

Добавление политик DNS

  1. Каждая политика DNS должна иметь имя, соответствующее правилам имен файлов. Имя должно быть уникальным для зоны или среди политик DNS на уровне сервера.

Примечание

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

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

  2. Каждый запрос, соответствующий политике, может привести к трем действиям:

Разрешить:

Запрос обрабатывается и на него отвечает указанный сервер или область зоны.

Запретить:

DNS-сервер отклоняет запрос.

Игнорировать:

DNS-сервер отбрасывает запрос, не информируя об этом клиента.

Примечание

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

  1. Если выбрано действие «Разрешить», нажмите кнопку «Редактировать».Откроется диалоговое окно, в котором можно выбрать целевые области DNS, используемые для сопоставленных запросов, и вес для балансировки нагрузки.

  2. Условие определяет условие для соответствия списку критериев. Выбор «И» означает, что для применения политики должны совпадать все критерии, а «Или» указывает, что для применения политики достаточно одного или нескольких критериев.

  3. Критерии — это список правил, с которыми сравнивается входящий DNS-запрос. Если запрос соответствует правилам, сервер выполняет соответствующие действия.Дополнительные сведения см. в разделе Добавление критериев политики DNS.

Добавление целевой области политики DNS

Если для политики DNS выбрано действие «Разрешить», необходимо выбрать одну или несколько целевых областей DNS. Каждая область DNS имеет имя и вес для балансировки нагрузки.

  1. Чтобы добавить область DNS в список, нажмите кнопку Добавить.

  2. В диалоговом окне «Добавить целевую область» вы можете выбрать область, которую вы хотите использовать для ответов на запросы, соответствующие списку критериев политики DNS.Будут перечислены области DNS для DNS-сервера или зоны. Чтобы создать новую область DNS, см. разделы Добавление области сервера и Добавление области зоны соответственно.

Целевая область:

Область DNS, используемая для ответа на запрос.

Примечание

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

Вес:

Целочисленное значение, используемое для балансировки нагрузки.

Примечание

Политики DNS

можно использовать для балансировки нагрузки на основе DNS. Для зон этого можно добиться, добавив записи DNS, которые вы хотите сбалансировать по нагрузке (обычно записи A/AAAA), в разные области DNS, а затем создав политику обработки запросов, которая будет соответствовать входящим запросам и имеет «Разрешено» в качестве действия. затем добавьте области DNS в качестве целевых областей для политики DNS.

Ответы на запросы будут получены из целевых областей в циклическом режиме на основе веса. Если целевыми областями являются «example.com» с весом 4 и «разгрузка» с весом «2», то первые 4 запроса, соответствующие этой политике, будут отвечать из области «example.com», а следующие 2 — из области «example.com». объем разгрузки. Подобная балансировка нагрузки также может быть достигнута с другими типами политик DNS.

Добавление критериев политики DNS

Каждая политика DNS имеет список критериев, которые вместе с условием политики определяют способ сопоставления политики DNS.В зависимости от типа политики допускаются разные критерии.

Критерии политики DNS и их описания:

. .

Тип

Описание

Подсеть клиента

Список имен подсетей, определенных на сервере. Дополнительные сведения см. в разделе Определение клиентских подсетей.

Транспортный протокол

Список транспортных протоколов, используемых во входящем запросе.Возможные транспортные протоколы: UDP и TCP.

Сетевой протокол

Список сетевых протоколов, используемых запросом. Возможные сетевые протоколы: IPv4 и IPv6.

Интерфейс сервера

Список IP-адресов, которые прослушивает DNS-сервер.

Имя домена

Список доменных имен со строго разрешенными подстановочными знаками.Например, «*.example.com»

Тип запроса

Список типов записей DNS. Например, A, NS, SRV, CNAME

Время суток

Список периодов времени в 24-часовом формате. Например 18:00-23:15. Время суток округляется MS-DNS до следующих 15 минут. Может быть, мы должны указать это в примечании и полностью избегать примеров, которые будут округлены.

Оператор:

Поддерживаемые значения: «есть» или «нет», где не отменяет ВСЕ значения, указанные в поле ввода «Значения».

Значения:

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

Примечание

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

Применить политику DNS от

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

Примечание

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

  1. Щелкните правой кнопкой мыши DNS-сервер или зону DNS.

  2. Выберите «Применить политику DNS из…» в подменю «Редактировать политику DNS».

  1. Выберите тип политики DNS для копирования.

  2. Выберите DNS-сервер или зону DNS для копирования политик DNS из

DNS на основе политик » Журнал ADMIN

Негибкое разрешение DNS-имен было решено в Windows Server 2016 благодаря DNS на основе политик.

Поставщики

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

Это отсутствие гибкости компенсируется либо самим приложением, контролирующим клиентский доступ в зависимости от местоположения Active Directory (AD) (например, Exchange), либо администраторами, публикующими приложение в разных местах под разными именами и передающими эти имена правильные клиенты. Для клиентов, которые постоянно остаются в одном месте, этот обходной путь обычно работает достаточно хорошо, но при частых перемещениях часто что-то идет не так. Кроме того, веб-службы затрудняют управление несколькими именами, например, потому что SSL-сертификаты должны быть выданы на разные имена, а сертификаты с подстановочными знаками недоступны.

DNS на основе политик

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

Рассмотрим практический пример: компания (назовите ее «Contoso», как это принято в Microsoft) с офисами в Германии, Японии и Канаде решила внедрить внутреннюю веб-платформу для совместной работы.Клиентская ферма состоит из корпоративных и частных устройств, включая смартфоны и планшеты, потому что сотрудники любят использовать политику использования собственных устройств. Таким образом, централизованное управление устройствами с помощью групповой политики невозможно, и вы не можете выдавать доверенные внутренние сертификаты. Для решения этих задач вы используете имя веб-сайта публичной компании www.contoso.com . для внутренней платформы для совместной работы. Качественный SSL-сертификат крупного провайдера, которому доверяют все устройства, уже существует.Однако это также пространство имен домена AD компании. DNS предоставляется исключительно на контроллерах домена (DC), и вы хотите оставить его таким, если это возможно.

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

  • Немецкая ферма веб-серверов (10.0.101.99) должна быть доступна из всех продуктивных сетевых сегментов немецкого сайта под www.contoso.com .
  • То же самое относится к местоположениям в Канаде (10.0.102.99) и Японии (10.0.103.99).
  • Из гостевых сетей, www.contoso.com должен разрешаться в общедоступный IP-адрес 40.84.199.233.

Эту задачу можно решить с помощью DNS на основе политик всего за несколько шагов, но для этого вам понадобится PowerShell с модулями DNS и AD (например, на DC), который нужно запустить с повышенными правами. Сначала определите запись по умолчанию для www.contoso.com :

 > Add-DnsServerResourceRecordA -Name "www" -ZoneName "contoso.com" -IPv4Address "40.84.199.233" 

Теперь разместите клиентские подсети на всех контроллерах домена (листинг 1).

Размещение клиентских подсетей на контроллерах домена

 > $dcs = (Get-ADDomainController -Filter *).Имя
> foreach ($dc в $dcs) {
    Add-DnsServerClientSubnet -Name "DE-Prod" -IPv4Subnet "10.0.101.0/24" -ComputerName $dc
    Add-DnsServerClientSubnet -Name "CA-Prod" -IPv4Subnet "10.0.102.0/24" - имя_компьютера $dc
    Add-DnsServerClientSubnet -Name "JP-Prod" -IPv4Subnet "10.0.103.0/24" -ComputerName $dc
  } 

В зависимости от того, из какой клиентской подсети поступает запрос, DNS-сервер должен давать разные ответы. Для этого необходима так называемая «область зоны» в зоне DNS contoso.com . для каждого сайта:

 > Add-DnsServerZoneScope - ZoneName "contoso.com" -Name "DE"
> Add-DnsServerZoneScope - ZoneName "contoso.com" -Name "CA"
> Add-DnsServerZoneScope -ZoneName "contoso.com" -Name "JP" 

Теперь добавьте запись A для www.contoso.com с соответствующим IP-адресом для каждой области зоны (листинг 2). Чтобы установить зависимость от местоположения, вы будете определять три политики DNS, которые должны быть развернуты индивидуально на каждом сервере (листинг 3).

Добавление записей в области действия зоны

 > Add-DnsServerResourceRecordA -Name "www" -ZoneName "contoso.com" -ZoneScope "DE" -IPv4Address "10.0.101.99"
> Add-DnsServerResourceRecordA -Name "www" -ZoneName "contoso.com" - ZoneScope "CA" -IPv4Address "10.0.102.99"
> Add-DnsServerResourceRecordA -Name "www" -ZoneName "contoso.com" -ZoneScope "JP" -IPv4Address "10.0.103.99" 
 > $dcs = (Get-ADDomainController-Filter *).Имя
> foreach ($dc в $dcs) {
    Add-DnsServerQueryResolutionPolicy -Name "Client Subnet DE" -ClientSubnet "EQ,DE-Prod" -ZoneName "contoso.com" -ZoneScope "DE,1" -Action ALLOW -ComputerName $dc
    Add-DnsServerQueryResolutionPolicy -Name "Client Subnet CA" -ClientSubnet "EQ,CA-Prod" -ZoneName "contoso.com" -ZoneScope "CA,1" -Action ALLOW -ComputerName $dc
    Add-DnsServerQueryResolutionPolicy -Name "Client Subnet JP" -ClientSubnet "EQ,JP-Prod" -ZoneName "contoso.com" -ZoneScope "JP,1" -Action ALLOW -ComputerName $dc
  } 

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

Внутренние процессы системы

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

 DC=DomainDNSZones,DC=contoso,DC=com 

, как показано на рис. 1. Однако даже зона DNS на основе файлов может включать области зоны.Данные области находятся здесь, вместе с зоной, с тем же именем, что и подкаталог: C:\Windows\System32\DNS\ (рис. 2).

Рис. 1. Области зоны с соответствующими записями скрыты в системе и отображаются только при использовании ADSI Edit. Рис. 2. Зоны DNS на основе файлов хранят данные своей зоны в подкаталоге C:\Windows\System32\.

Файлы имеют формат DNS по умолчанию, и контейнер области зоны в AD и подкаталог в папке DNS будут созданы только в том случае, если для зоны создана область зоны.Однако области действия файловой зоны DNS не будут передаваться даже между двумя компьютерами под управлением Windows Server 2016. Если вы действительно хотите назначить области зоны зонам на основе файлов, вам необходимо управлять областями зоны и их соответствующими записями отдельно на каждом сервере или передавать файлы областей с главного сервера каким-либо другим способом. Однако в каждом случае необходимо создать область зоны для каждого сервера; в противном случае файлы не будут найдены (рис. 3).

Рис. 3. Области зоны необходимо создавать отдельно на каждом сервере.

Клиентские подсети и политики DNS всегда хранятся только на сервере и в ветке реестра HKLM\Software\Microsoft\Windows NT\CurrentVersion\DNS Server\ . Имена ключей и значений, а также содержимое записей реестра доступны здесь и, следовательно, позволяют проводить инвентаризацию, документирование и диагностику с использованием проверенных и надежных инструментов, если нет доступных инструментов, специально предназначенных для DNS на основе политик.

Как работают политики DNS

Принципы работы политик DNS больше похожи на правила брандмауэра, чем на групповую политику.Во-первых, действительно работает только первая политика, для которой применяются все условия. Во-вторых, политики DNS не настраивают никаких параметров; они только решают, отвечает ли DNS-сервер на запрос ( ALLOW ), игнорирует его ( IGNORE ) или отклоняет ответ ( DENY ). Ответ, возвращенный в приведенном выше примере для адреса IPv4 на запрос www.contoso.com включен в конфигурацию DNS. Поэтому политики DNS для каждого DNS-клиента, соответствующего стандартам, полностью прозрачны.

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

  • При получении DNS-запроса политики на уровне сервера сначала проверяются в том порядке, в котором они были определены ( -ProcessingOrder ). Если выполняются все условия политики, она используется, и обработка завершается. Поскольку на данный момент еще не гарантируется, что на сервере действительно размещается запрошенная зона, в результате политики уровня сервера могут иметь только DENY или IGNORE .
  • Если ни одна из политик уровня сервера не применяется, запрошенная зона DNS вступает в действие. Если сервер является полномочным для этой зоны, политики уровня зоны проверяются и выполняются, если выполняются условия. Если сервер не является авторитетным, он ответит на запрос.
  • По умолчанию условия внутри политики объединяются по И. Другими словами,
 -ClientSubnet 'EQ,JP-Guest' -QueryType 'NE,SRV' 

будет применяться ко всем запросам, поступающим из подсети JP-Guest и не относящимся к типу SRV .Если вы хотите изменить это поведение и ИЛИ критерии разных типов, используйте параметр -Condition , который принимает значения И (по умолчанию) и ИЛИ .

  • Каждое условие должно включать одно или оба выражения EQ,значение1,значение2, … или NE,значение1,значение2, …. Возможные значения в предложении EQ объединяются по И (условие применяется, если ни одно из значений NE не подходит). Принимая во внимание, что значения в предложении NE объединяются по И (условие применяется, если ни одно из значений NE не подходит).
  • Несколько политик на одном уровне (т. е. на уровне сервера или в одной зоне) должны иметь разные ранговые номера (порядок обработки). Если вы добавите новую политику и укажете назначенный номер ранга, ваша новая политика получит запрошенный порядок обработки, а существующие политики в ранжировании переместятся на слот вниз.

Вы можете использовать следующие типы критериев для управления поведением вашего DNS-сервера: клиентская подсеть, транспортный протокол (TCP или UDP), интернет-протокол (IPv4 или IPv6), IP-адрес DNS-сервера (если он прослушивает несколько интерфейсы), полное доменное имя (FQDN) запроса (в начале допускаются подстановочные знаки, т.г., *.contoso.com ), тип запроса (A, TXT, SRV, MX и т. д.) и время в местном часовом поясе DNS-сервера. Отдельные критерии подробно описаны на TechNet [1].

Как развернуть DNS-сервер для Windows Server 2016: процессы и конфигурации

Установка служб DNS в Windows Server 2016

В Windows Server программы и функции DNS объединены в одну роль, чтобы облегчить установку и настройку служб. При выборе установки роли DNS программа настройки сервера Server Manager автоматически установит все необходимые программные зависимости и инструменты управления.После завершения этого процесса вы можете сразу начать использовать сервер имен в клиентах вашей сети.

Вы можете установить собственный DNS-сервер, выполнив следующие действия:

  1. Выполните аутентификацию в качестве администратора сервера на целевой машине. Вы не можете установить роль DNS без соответствующих административных учетных данных.
  2. Запустите программу PowerShell с полными правами администратора на панели задач или в меню «Пуск». Вы должны щелкнуть правой кнопкой мыши ярлык программы и выбрать параметр «Запуск от имени администратора», чтобы инструмент командной строки работал правильно.
  3. Запустите следующий командлет PowerShell, чтобы установить роль DNS на Windows Server:
    • Install-WindowsFeature DNS-IncludeManagementTools

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

DNS-серверы Windows Server имеют гораздо больше функций, например, управление зонами DNS для одной. Зоны DNS, такие как зоны прямого просмотра и зоны обратного просмотра, являются основой Интернета, поскольку они обеспечивают центральное место для настройки полезной информации, которую могут использовать все клиенты.

Давайте настроим новую зону на нашем новом сервере имен.

Создание зон DNS

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

Существуют разные типы зон для разных целей: первичные, вторичные и заглушки.

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

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

  1. Войдите в систему как администратор сервера, затем откройте программу диспетчера серверов из меню «Пуск».
  2. Щелкните меню Сервис, затем выберите DNS, чтобы открыть утилиту управления службой DNS.
  3. Щелкните правой кнопкой мыши целевой DNS-сервер, на котором вы хотите создать новую зону, и выберите «Создать новую зону», затем нажмите «Далее», чтобы продолжить.
  4. Выберите Первичную зону, чтобы настроить доверенную зону DNS.
  5. Выберите Зона прямого просмотра , если вы хотите преобразовать имена хостов в IP-адреса, или выберите Зона обратного просмотра , если вы хотите преобразовать IP-адреса в имена хостов.Нажмите Далее, чтобы продолжить.
  6. Укажите имя зоны, например адрес вашего веб-сайта, и нажмите Далее. Имя зоны будет использоваться при разрешении имен для завершения полных имен узлов, таких как pc25.example.com, где example.com — имя зоны.
  7. Выберите «Создать новый файл с этим именем» и нажмите «Далее», чтобы продолжить. При этом зона будет сохранена под своим именем, чтобы ее можно было отличить от любых аналогичных конфигураций зоны.
  8. Выберите «Не разрешать динамические обновления», чтобы запретить клиентам автоматически обновлять зону при изменении их клиентского IP-адреса.В противном случае выберите другой вариант, чтобы включить динамические обновления.
  9. Нажмите Готово, чтобы завершить процесс создания новой зоны.

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

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

Сейчас зона пуста, за исключением записей Start of Authority (SOA) и Name Server (NS), определяющих, какой сервер находится под управлением.Создав записи ресурсов, также известные как записи A (для IPv4) и записи AAAA (для IPv6), клиенты смогут искать эти имена хостов здесь.

Пустая первичная зона DNS с записями SOA и NS.

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

Вы можете создать новые записи ресурсов, выполнив следующие действия:

  1. Откройте утилиту управления службой DNS, если она еще не открыта, следуя предыдущим инструкциям.
  2. Выберите созданную вами зону (в разделе «Зоны прямого просмотра»), чтобы перемещаться внутри нее, что позволяет управлять ее конфигурацией и контролировать ее по мере необходимости.
  3. Щелкните правой кнопкой мыши в любом месте окна, показывающем зону, и выберите параметр «Новый хост (A или AAAA)». A записывает , переводит имена хостов в адреса IPv4, а AAAA записывает , переводит имена хостов в адреса IPv6.
  4. Введите сведения о записи, например, имя хоста, для которого предназначена эта запись, и адрес, на который она указывает. Чтобы автоматически создать соответствующую обратную (PTR) запись для этого имени хоста, оставьте выбранным «Создать связанную запись указателя».
  5. Щелкните Добавить хост, чтобы добавить новую запись ресурса в эту основную зону.
Добавление записи pc01 в зону example.net для IPv4-адреса 10.0.0.1

Теперь вы можете создавать другие записи, необходимые для вашей сети.Мы перейдем к объяснению дополнительных функций службы DNS Windows Server 2016, таких как серверы пересылки и корневые ссылки.

Конфигурация DNS-сервера и корневые подсказки

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

При первом открытии свойств вашего DNS-сервера вы попадете в раздел «Интерфейсы».Здесь вы можете выбрать, какие IP-адреса должна прослушивать служба DNS, но есть и другие параметры, показанные на разных вкладках.

Вы также можете настроить:

  • Серверы пересылки DNS — пересылать запросы, для которых DNS-сервер не уполномочен, на другой сервер.
  • Дополнительные параметры сервера — включение/отключение рекурсии и защита сервера от различных атак.
  • Ведение журнала отладки — регистрируйте проблемы сервера, чтобы сообщать об этом организациям поддержки.
  • Регистрация событий — Запись запросов к серверу в целях безопасности или по другим причинам.
  • Мониторинг — проверка состояния и производительности сервера с помощью различных запросов.
  • Корневые подсказки — используются в случае, когда никакие серверы пересылки не настроены на рекурсивный поиск интернет-имен и IP-адресов.

Корневые подсказки позволяют DNS-серверу отвечать на запросы интернет-сервисов путем рекурсивного поиска и состоят из 13 корневых серверов с именами от A до M (например, h.root-servers.net — один). Если вы отправите запрос для example.com на DNS-сервер с поддержкой корневой подсказки, он сначала будет использовать корневой сервер имен для поиска авторитетного сервера для .com домен верхнего уровня, затем действуйте оттуда.

Экран конфигурации DNS Root Hints, на котором показаны активные корневые серверы и кнопка «Копировать с сервера» для обновления корневых ссылок.

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

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

Сводка урока

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

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

Вы можете создавать новые записи ресурсов в основных зонах для сетей IPv4 ( A ) и IPv6 ( AAAA ), а также управлять дополнительными функциями, такими как серверы пересылки (отправка неавторизованных запросов на другой сервер) и корневые подсказки . (рекурсивный поиск интернет-имен и адресов с использованием специальных серверов) в свойствах DNS-сервера.

Настройка дополнительной зоны — Windows Server 2016 · ReadAndExecute

Это руководство по настройке дополнительной зоны с помощью диспетчера DNS.Чтобы сделать это с помощью PowerShell, см. раздел Настройка дополнительной зоны с помощью PowerShell — Windows Server Core 2016.

Практическое руководство
Предпосылки

Перед запуском на сервере должна быть установлена ​​роль DNS. Чтобы установить роль DNS, см. одну из следующих статей:

Установка роли DNS с помощью PowerShell — Windows Server Core 2016

Установка роли DNS с помощью диспетчера серверов — Windows Server 2016

Предположения

В этом руководстве я добавляю вторичную зону на удаленный сервер (Test-DNS16) с сервера, имеющего основную зону (Test-DC16).

1) Откройте Диспетчер DNS

Откройте окно «Выполнить» с помощью Win+R, введите dnsmgmt.msc и нажмите OK

.

2) Подключиться к удаленному серверу, на котором будет дополнительная зона

Если вы находитесь на сервере, который получает дополнительную зону, пропустите этот шаг

Щелкните правой кнопкой мыши DNS и выберите Подключиться к DNS-серверу…

Введите имя сервера и нажмите OK

Теперь вы должны увидеть другой DNS-сервер в списке

3) Откройте Мастер создания новой зоны

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

.

Щелкните правой кнопкой мыши Зоны прямого просмотра и выберите Новая зона…

4) Нажмите Далее

5) Выберите Вторичная зона, затем нажмите Далее

6) Введите имя зоны или нажмите Обзор

Если вы знаете имя зоны, введите его и пропустите шаг 7

Если вы не знаете имя, нажмите Обзор

7) Выберите зону

Выберите сервер, содержащий основную зону

Выберите  Зоны прямого просмотра

Выберите зону, которую хотите скопировать, и нажмите OK

8) Нажмите Далее

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

Нажмите Далее

9) Добавьте главные серверы

Введите IP-адреса или полные доменные имена серверов, на которых находится копируемая основная зона

Нажмите Далее

10) Нажмите Готово

Нажмите Готово , чтобы завершить процесс и добавить дополнительную зону

Теперь вы успешно добавили дополнительную зону!

Если вы получаете сообщение «Зона не загружена DNS-сервером», см. ниже

Зона не загружена DNS-сервером

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

1) Открыть свойства

Щелкните правой кнопкой мыши зону под главным сервером и выберите Свойства

2) Откройте окно «Новая запись сервера имен»

Перейдите на вкладку Name Servers и нажмите  Добавить

3) Введите DNS-сервер

Введите полное доменное имя DNS-сервера с дополнительной зоной и нажмите  Разрешить

или

Введите IP-адрес

Нажмите ОК

4) Настройте параметры передачи зоны

Перейдите на вкладку Zone Transfers  

.

Установите флажок Разрешить передачу зон .

Выберите Только для серверов, перечисленных на вкладке Серверы имен переключатель

Нажмите кнопку  Уведомить

5) Откройте окно «Новая запись сервера имен»

Установите флажок Автоматически уведомлять

Выберите Серверы, перечисленные на вкладке Серверы имен переключатель

Нажмите ОК

6) Применить настройки

 

Нажмите ОК

7) Зона передачи от мастера

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

Щелкните правой кнопкой мыши зону под вторичным сервером и выберите  Передача с главного сервера

Теперь должны отображаться записи с главного сервера

 

Настройка основных записей DNS в Windows Server 2008 R2 и 2012

После запуска DNS-сервера Windows и настройки зоны прямого и обратного просмотра он готов к настройке записей DNS.Эта статья начнется с краткого обзора основных типов записей DNS, а затем будет рассмотрена конфигурация основных типов записей DNS в Windows Server 2008 r2 и Windows Server 2012.

 

(Нужно наверстать упущенное? Обязательно ознакомьтесь с другими нашими статьями из этой серии: «Установка роли DNS-сервера в Windows Server 2008 R2», «Установка роли DNS-сервера в Windows Server 2012» и «Настройка прямого и обратного Зоны поиска в Windows Server 2008 R2 и 2012.”)

Основные типы записей DNS

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

  • Запись адреса (A) — Этот тип записи используется для преобразования доменного имени в определенный IPv4-адрес.
  • Адресная запись (AAAA) — Этот тип записи используется для преобразования доменного имени в определенный IPv6-адрес.
  • Запись канонического имени (CNAME) — Этот тип записи используется для указания вторичного имени (обычно называемого псевдонимом ) для существующей записи A или AAAA.
  • Запись почтового обмена (MX) — Этот тип записи используется для управления почтовыми сообщениями для определенных доменов в Интернете. Запись включает в себя приоритет и доменное имя агента почтового обмена (это ссылка на существующие A, AAAA или CNAME).
  • Запись Start of Authority (SOA) — Этот тип записи обычно настраивается с созданием зоны и включает достоверную информацию об определенном доменном имени.
  • Запись сервера имен (NS) — Это делегирует полномочные серверы имен для определенного домена, эта запись также обычно настраивается при создании зоны (в простых конфигурациях).

Прохождение базовой записи DNS

Это пошаговое руководство предназначено для Windows Server 2012, но аналогичные действия можно выполнить и для Windows Server 2008 R2. В качестве отправной точки используется панель мониторинга диспетчера серверов, но для доступа к диспетчеру DNS можно использовать любой метод.На рисунке 1 ниже показано, что роль DNS-сервера установлена ​​и может быть выбрана на левой панели.

 

  • После выбора DNS отобразятся доступные DNS-серверы. Щелкните правой кнопкой мыши целевой сервер и выберите DNS Manager , как показано на рис. 2 ниже.

 

Теперь откроется диспетчер DNS. На изображении ниже видно, что созданы зоны прямого и обратного просмотра.

 

  • Выберите зону прямого просмотра , которая откроет список существующих записей зоны. На рис. 4 ниже показаны основные записи, которые автоматически создаются мастером настройки DNS. Первая запись, которая будет создана, — это запись A , связывающая имя родительского домена (в данном случае testing.local) с IPv4-адресом 192.168.1.100.

 

  • Щелкните правой кнопкой мыши на правой панели и выберите Новый хост (A или AAAA) .Появится окно, показанное ниже на рис. 5.
  • Теперь заполните текстовое поле IP-адреса целевым адресом 192.168.1.100 .
  • Нажмите на запись Создать связанный указатель (PTR) и выберите Добавить хост .

 

  • Это покажет успешное создание записи. Выберите OK и верните окно «Добавить хост», если необходимо создать несколько записей
  • Выбрать Закрыть .Теперь на экране появится новая запись A с введенной информацией.

 

  • Щелкните реверсивную зону , которая была создана ранее. Обратите внимание, что теперь существует новая запись PTR (как показано ниже на рис. 7). Эта запись позволит выполнить обратный поиск записи 192.168.1.100 к доменному имени testing.local.

 

  • Вернитесь в зону переадресации, затем снова щелкните правой кнопкой мыши на правой панели и выберите Новый псевдоним (CNAME) .Появится окно, показанное на рисунке 8.
  • На этом этапе введите www в текстовом поле Псевдоним и введите testing.local в поле Полное доменное имя (FQDN) для целевого хоста текстовое поле. Это создаст запись псевдонима для www.testing.local, которая сопоставляется с записью A для testing.local.

 

  • Выберите Next , это вернет главное окно диспетчера DNS (как показано на рис. 9) с новой записью CNAME.

 

  • Следующий тип записи, который будет создан, — это запись MX . Щелкните правой кнопкой мыши на правой панели и выберите New Mail Exchanger , после чего откроется окно, показанное на рис. 10. В этом окне будет настроено только «Полное доменное имя (FQDN) почтового сервера». текстовое окно. Это связано с тем, что почта направляется для всего домена testing.local, а не для конкретных поддоменов. Имя, помещенное в это текстовое поле, является именем почтового сервера, в данном случае mail.test.local . (Запись A для mail.testing.local была добавлена ​​до этого шага, но не рассматривалась в пошаговом руководстве).

 

  • После завершения выберите OK . Это вернет главное окно диспетчера DNS с новой записью MX.

 

Последняя запись, которая будет показана как созданная, — это запись AAAA , которая похожа на запись A, но работает с адресом IPv6 вместо адреса IPv4.

  • Щелкните правой кнопкой мыши на правой панели и выберите Новый хост (A или AAAA) . Появится окно, показанное на рисунке 12 (и рисунке 5). В этом окне введите IPv6-адрес 2001:DB8::1 , чтобы связать имя родительского домена.

 

  • После завершения выберите Добавить хост , затем выберите OK .
  • Выберите Готово , чтобы вернуться в главное окно диспетчера DNS, показанное ниже. Это окно показывает, что новая запись узла была создана с использованием адреса IPv6.

 

И, наконец, эти записи можно проверить с помощью команды Windows nslookup . Как показано ниже, различные записи отображаются правильно.

 

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

.

Добавить комментарий

Ваш адрес email не будет опубликован.