Создание и настройка зон DNS. Создание и настройка зон DNS Что такое DNS

10.10.2022

DNS (или также известная как Система доменных имен) — это система, которая сопоставляет доменные имена, такие как Google.com или Yandex.ru, с правильными IP-адресами. Эта система представляет собой базу данных доменных имен и IP-адресов. Он используется для ведения каталога доменных имен и помогает преобразовать эти доменные имена в правильные IP-адреса.

Доменные имена — это удобочитаемые адреса, которые мы используем каждый день. Например, доменное имя Yandex — yandes.ru. Если вы хотите посетить веб-сайт Яндекс, просто введите yandex.ru в адресную строку веб-браузера.

Но ваш компьютер не знает, где находится «yandex.ru». За кулисами ваш компьютер свяжется с DNS-серверами и спросит, какой IP-адрес связан с yandex.ru.

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

В этом случае yandex.ru находится по IP-адресу 77.88.55.70 в Интернете. Вы можете ввести этот IP-адрес в своем веб-браузере, чтобы посетить веб-сайт Yandex. Однако вместо 77.88.55.70 мы используем «yandex.ru», потому что его легче запомнить.

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

Конечно, это просто простое объяснение, на самом деле, это немного сложно. Для получения дополнительной информации, я бы порекомендовал вам прочитать эту статью или посмотреть видео ниже.

Разные интернет-провайдеры (ISP) используют разные DNS-серверы. По умолчанию, если вы не настроили определенные DNS-серверы на своем компьютере (или маршрутизаторе), будут использоваться DNS-серверы по умолчанию от вашего интернет-провайдера.

Если эти DNS-серверы нестабильны, возможно, у вас возникли некоторые проблемы при использовании Интернета на вашем компьютере. Например, не может загрузить веб-сайты полностью или не имеет доступа к Интернету. Чтобы избежать нежелательных ошибок DNS, переключитесь на общедоступные DNS-серверы, такие как Google DNS и OpenDNS.

Вот несколько распространенных ошибок, связанных с DNS, которые вы можете посмотреть:

Исправлена ошибка поиска DNS в Google Chrome
Как исправить ошибку Err_Connection_Timed_Out
Как исправить ошибку Err_Connection_Refused
Исправить Dns_Probe_Finished_Nxdomain Ошибка
Исправить DNS-сервер не отвечает на Windows

Вы можете исправить эти ошибки, перейдя на сторонние DNS-серверы в списке ниже.

Преимущества использования публичных DNS-серверов

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

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

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

После прочтения объяснения того, что такое DNS-сервер, полезны сторонние DNS-серверы, ознакомьтесь со списком ниже. Это список топ-10 лучших сторонних DNS-серверов:

1. Публичный DNS-сервер Google

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

Чтобы использовать общедоступные DNS-серверы Google, настройте параметры сети со следующими IP-адресами:

8.8.8.8 в качестве предпочитаемого DNS-сервера

8.8.4.4 в качестве вашего альтернативного DNS-сервера

2. OpenDNS

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

Чтобы использовать OpenDNS, давайте настроим параметры вашей сети со следующими IP-адресами:

208.67.222.222

208.67.222.220

OpenDNS также предлагает два бесплатных решения для частных клиентов: OpenDNS Family Shield и OpenDNS Home.

Семейство OpenDNS Shield поставляется с предварительно настроенным для блокировки контента для взрослых. Чтобы использовать его, в настройках сети необходимо настроить разные DNS-серверы со следующими IP-адресами.

Предпочитаемый DNS-сервер: 208.67.222.123

Альтернативный DNS-сервер: 208.67.220.123

Между тем, OpenDNS Home поставляется с настраиваемой защитой от кражи и фишинга.

3. Norton ConnectSafe

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

Norton ConnectSafe поставляется с тремя заранее определенными политиками фильтрации содержимого. Это безопасность, безопасность + Порнография и безопасность + Порнография + прочее.

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

4. Comodo Secure DNS

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

Если вы хотите использовать Comodo Secure DNS, вам не нужно устанавливать какое-либо оборудование или программное обеспечение. Просто измените ваш основной и дополнительный DNS-серверы на 8.26.56.26 и 8.20.247.20.

5. Уровень 3

Level3 — следующая бесплатная служба DNS в этом списке. Он работает на уровне 3 связи. Чтобы воспользоваться этой бесплатной услугой, просто настройте параметры сети с помощью следующих IP-адресов DNS:

209.244.0.3

208.244.0.4

Посетите для более подробной информации.

6. Преимущество DNS

Это один из самых быстрых DNS-серверов, обеспечивающих наилучшую производительность при работе в Интернете. Это поможет вам загружать сайты быстрее и безопаснее. Чтобы использовать DNS Advantage, настройте предпочтительные / альтернативные DNS-серверы со следующими подробностями:

156.154.70.1

156.154.71.1

7. OpenNIC

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

46.151.208.154

128.199.248.105

Чтобы найти более надежные DNS-серверы.

8. Дин

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

216.146.35.35

216.146.36.36

9. SafeDNS

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

195.46.39.39

195.46.39.40

О бесплатных и премиальных услугах DNS от SafeDNS.

10. DNS.Watch

DNS.Watch является последней бесплатной общедоступной службой DNS в этом списке. Это обеспечивает цензуру, быстрый и надежный опыт просмотра веб-сайтов бесплатно. Чтобы настроить свой ПК или маршрутизатор с помощью «DNS.Watch», используйте два IP-адреса DNS ниже:

84.200.69.80

84.200.70.40

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

Не знаете, как изменить DNS-серверы на Windows, Mac или Android? Просто прочитайте .

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

Примечание. Если ваша установка Plesk не использует собственную службу DNS и не позволяет настраивать параметры DNS на удаленном сервере DNS, вы можете только просматривать информацию о своем зарегистрированном доменном имени. Ссылка Настройки DNS на вкладке Сайты и домены будет заменена на ссылку Информация Whois .

Преобразование доменных имен

В основе DNS лежит иерархическая древовидная структура, которая называется пространством доменных имен. Глобальное пространство доменных имен содержит все возможные доменные имена и разделено на логические части - доменные зоны (смотрите рисунок ниже). Доменная зона - это часть пространства имен, которая содержит адреса конкретных доменов. Адреса хранятся в специальном файле на отдельном DNS-сервере, авторитетном для этой зоны. Например, когда браузер пытается открыть сайт www.example.com , он запрашивает его IP-адрес у сервера, авторитетного для зоны example.com . Более подробную информацию о принципе работы DNS смотрите в соответствующей документации. Ее можно легко найти в Интернете, например, на сайте Microsoft TechNet .

Примечание. Многие регистраторы просят предоставить адреса по крайней мере двух отдельных серверов имен при покупке доменного имени. По умолчанию Plesk предоставляет только один сервер имен. Если вам нужен второй сервер имен, пожалуйста, обратитесь к своему провайдеру.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. TCP и UDP

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

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

4. DNS в Windows Server 2008 и 2012

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

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

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

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

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

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

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

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

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

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

5. DNS и Active directory

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Настройку dns windows server 2012 r2 мы начнем с открывания оснастки Диспетчер DNS. Как видите, contoso.com еще пустая.

Для этого идем на ваш Контроллер домена, у меня это dc. Выбираем свойства нужной зоны

Идем на вкладку сервера имен. Нажимаем Добавить

пишем имя нужного сервера, у меня это sccm

В итоге у меня получился вот такой список.

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

Передача зон, по сути, представляет собой извлечение данных, инициируемое в дополнительных зонах, копирование данных главной зоны, которая сама по себе может быть основной или еще одной дополнительной зоной. Главной зоне необязательно даже быть стандартной по отношению к дополнительной зоне - вы можете отконфигурировать дополнительную зону для основной зоны, интегрированной в Active Directory. К примеру, у вас есть два сайта - один в Нью-Йорке, другой в Лос-Анджелесе, причем каждый сайт принадлежит отдельному домену Active Directory. В каждом домене можно обеспечить разрешение имен для противоположного домена, не устанавливая новый контроллер домена и не управляя трафиком репликации между двумя сайтами.

Включение передачи зон

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

■ По истечении интервала обновления начальной записи SOA основной зоны.

■ При загрузке дополнительной зоны сервером.

■ В результате изменения конфигурации основной зоны, если эта зона настроена для уведомления дополнительной зоны об обновлениях.

По умолчанию передача для всех зон отключена. Ее нужно включить на вкладке Передача зон (Zone Transfers) окна свойств зоны. Установив флажок разрешения передачи зон, можно выбрать одни из трех параметров передачи.

■ На любой сервер (To Any Server) Этот параметр обеспечивает минимальную безопасность. Поскольку передача зоны представляет собой копирование данных зоны, этот параметр позволяет кому угодно с сетевым доступом к DNS-серверу просмотреть содержимое зоны, включая имена всех серверов и компьютеров с их IP-адресами. Поэтому данный параметр следует использовать только в частных сетях с высоким уровнем безопасности.

■ Только на серверы, перечисленные на странице серверов зон (Only To ServersListed On The Name Servers Tab) Этот параметр позволяет выполнять передачу зон с записью NS только на те дополнительные DNS-серверы, которые полномочны для данных зон.

■ Только на серверы из этого списка (Only To The Following Servers) Этот параметр позволяет указать список дополнительных серверов, на которые будет выполняться передача зон. Для этих дополнительных серверов не требуется идентификация с помощью записи NS в зоне.

Настройка уведомлений

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

Для настройки уведомлений на вкладке Передача зон (Zone Transfers) щелкните кнопку Уведомить (Notify). Откроется диалоговое окно Уведомление (Notify), где можно указать дополнительные серверы, которые будут оповещаться при обновлении зоны на локальном главном сервере.

По умолчанию при включении передачи зон все серверы, перечисленные на вкладке Серверы имен (Name Servers), автоматически уведомляются об обновлениях зоны.

Обновление дополнительной зоны вручную

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

Перезагружается дополнительная зона из локального хранилища.

■ Передать зону с основного сервера (Transfer From Master)

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

■ Перезагрузить повторно зону с основного сервера (Reload From Master)

Выполняется передача зоны с главного сервера дополнительной зоны независимо от серийного номера в записи SOA дополнительной зоны.

Выбираем Передать зону с основного сервера

Как видим если нажать F5 зона передалась

Все записи прилетели, единственное они не редактируемые.

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

Зона-заглушка

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

Зоны-заглушки можно использовать в следующих целях:

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

Существует два списка DNS-серверов, участвующих в загрузке и поддержке зоны-заглушки:

Список главных серверов, из которого DNS-сервер загружает и обновляет зону-заглушку. Главный сервер может быть главным или дополнительным DNS-сервером для зоны. В обоих случаях он будет располагать полным списком DNS-серверов для зоны.
Список полномочных DNS-серверов для зоны. Список содержится в зоне-заглушке с использованием записей ресурсов сервера имен (NS).

Создадим зону заглушку или как еще ее называют stub zone.

Щелкаем правым кликом по зоны прямого просмотра и выбираем создать

Откроется мастер создания зоны.

Выбираем зона заглушка

задаем имя зоны

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

Пишем имя главного dns с которого будем запрашивать зону

Видим что файл зоны заглушки лежим в папке windows\system32\dns

Файл кстати открывается любым текстовым редактором.

Пример зоны-заглушки

Предположим, вы работаете администратором DNS-сервера Dns1.microsoft.com, который уполномочен для зоны Microsoft.com. Ваша компания имеет дочерний домен Active Directory с именем India.microsoft.com, для которого выполняется делегирование. При начальном делегировании дочерняя зона, интегрированная иActive Directory, содержит только два полномочных DNS-сервера - 192.168.2.1 и 192.168.2.2. Позже администраторы домена India.microsoft.com развертывают дополнительные контроллеры домена и устанавливают роль DNS-сервер (DNSServer) на новых контроллерах. Однако администраторы не уведомили вас о том, что добавили полномочные DNS-серверы на свой домен. В результате на сервереDns1.microsoft.com оказались не отконфигурированными записи новых DNS-серверов, уполномоченных для домена lndia.microsoft.com, и запросы продолжают пересылаться лишь на два DNS-сервера, заданный в начальном делегировании.

Эту проблему можно устранить, создав зону-заглушку на сервере Dns1. microsoft.com для домена India.microsoft.com. С помощью новой зоны-заглушки компьютер Dns1 посредством передачи зон изучает новые серверы имен, уполномоченные для родительской зоны India.microsoft.com. Таким образом, сервер Dns1 сможет направлять запросы пространства имен Inclia.microsoft.com на все полномочные DNS-серверы дочерней зоны.

Теперь нужно понять как его настроить и как он работает.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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