общие вопросы о маршрутизации DNS

общие вопросы о маршрутизации DNS

Вопрос.У меня есть домен Windows AD, и есть одна загадка, которая для меня остается: как домен Windows / DNS-сервер выполняет поиск доменов за пределами домена Windows?

В простой домашней сети маршрутизация DNS-запросов понятна:

Generic Example: Client machine -> (defined DNS or from DHCP) -> 
                ->Router / Gateway -> (usually ISP DNS) -> DNS root servers -> Internet
Specific Example: 192.168.1.101 -> 192.168.1.1 -> 8.8.8.8 -> DNS root servers -> Internet

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

Client Machine -> Windows Domain / DNS -> ??????? -> DNS root servers -> Internet

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

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

решение1

Несколько способов, которыми ваши контроллеры домена могут направлять запросы внешнему серверу имен:

  1. Корневые подсказки
  2. Глобальные экспедиторы
  3. Явно определенные зоны-заглушки, делегирования или условные зоны пересылки
  4. Настройки сетевого интерфейса вашего контроллера домена, которые вы проверили.

Я угадаю № 1 или № 2. Ваш вопрос включает только проверку сетевых настроек — вы проверили DNS-менеджер на контроллерах домена?

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

решение2

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

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

Поскольку информация DNS хранится иерархически и распределенно, для ответа на один запрос вам понадобится информация с нескольких серверов контента DNS, вероятно, расположенных по всему миру. Когда клиент DNS хочет узнать адрес "www.serverfault.com", он может просто отправить этот запрос на сервер разрешения DNS. Затем этот сервер разрешения DNS должен выполнить фактическую работу по контакту с серверами DNS по всему миру.

Сначала разрешающий DNS-сервер отправляет весь запрос на корневой сервер (который является контентным DNS-сервером). У этого корневого сервера нет полного ответа, но онделаетзнать, какие серверы контента DNS имеют больше информации об именах в домене ".com". Поэтому DNS-резолвер теперь отправляет весь запрос на один из серверов контента DNS ".com". У этого сервера также нет полного ответа, но он знает, какие серверы контента DNS имеют больше информации об именах в домене servervault.com. Разрешающий DNS-сервер будет продолжать опрашивать серверы контента DNS по всему миру, пока не получит полный ответ для клиента. Конечно, разрешающий DNS-сервер будет кэшировать информацию по пути: он не будет связываться с корневыми серверами контента DNS для каждого запроса в домене ".com", если он знает из своего кэша, где находятся серверы контента DNS ".com".

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

Может возникнуть путаница, когда две разные роли (обслуживание контента и разрешение) объединяются на одном DNS-сервере. Примерно это и происходит с Active Directory. В Active Directory DNS используется для публикации информации о том, где можно найти определенные службы. Например, когда клиент в домене ad.example.comхочет связаться с сервером смены пароля Kerberos для своего домена, он отправляет DNS-запрос на запись SRV с именем _kpasswd._tcp.ad.example.com. Этот DNS-запрос отправляется, как и любой другой DNS-запрос, на разрешающий DNS-сервер, настроенный на клиенте. Затем разрешающий DNS-сервер пытается ответить на запрос.

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

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

Связанный контент