Условная пересылка DNS в Windows Server 2003

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

Экспедиторы и экспедирование

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

Однако иногда этого процесса недостаточно. Простой пример — компания, в которой Active Directory развернута во внутренней сети и использует частный домен верхнего уровня, например.local, для своего леса. Например, предположим, что у компании есть один домен Active Directory с именем test2003.local, контроллер домена (и DNS-сервер) с именем SRV220 и выделенное подключение к Интернету. Пользователь по имени Боб подходит к своему настольному компьютеру с именем DESK231, открывает Internet Explorer и пытается получить доступ к Google (www.google.com). Вот что происходит с DNS в отношении разрешения имен:

1. DESK231 отправляет рекурсивный запрос SRV220 с просьбой преобразовать www.google.com в связанный с ним IP-адрес.
2. SRV220 просматривает свою базу данных DNS и находит информацию о зоне только для домена test2003.local, понимает, что www.google.com не является частью этого домена, и решает, что не знает, как преобразовать www.google.com в IP-адрес., и что произойдет дальше, зависит:

   1. Если, когда вы повысили свой автономный сервер до роли контроллера домена с помощью dcpromo, ваша машина была отключена от Интернета и в вашей сети не было других DNS-серверов, то dcpromo создает корневую зону («.») в своей базе данных DNS. который указывает себя в качестве корневого сервера имен для всех разрешений имен DNS (то есть «на этом все останавливается»). В этом случае SRV220 понимает, что не может ответить на запрос, и возвращает клиенту ошибку «имя не найдено», а Боб не может открыть домашнюю страницу Google.
   2. Однако, если при повышении роли сервера до контроллера домена ваша машина была подключена к Интернету, Windows обращается к первому доступному корневому серверу имен Интернета и загружает список всех корневых серверов имен Интернета, который становится ее списком корневых ссылок. В этом случае разрешение имен теперь продолжается следующим образом:
3. SRV220 отправляет повторяющийся запрос на первый доступный корневой сервер имен в Интернете, который отвечает IP-адресом уполномоченного сервера имен для домена верхнего уровня.com.
4. SRV220 отправляет второй итеративный запрос полномочному серверу имен для домена.com, и эта машина отвечает IP-адресом уполномоченного сервера имен для домена google.com.
5. SRV220 отправляет третий итеративный запрос полномочному серверу имен для google.com, и эта машина отвечает IP-адресом хоста с именем www.google.com.
6. SRV220 возвращает IP-адрес www.google.com в DESK231, и Боб видит, что домашняя страница Google появляется в его браузере.

Теперь это много шагов, и если у компании есть медленная глобальная связь с Интернетом, вы используете ценную полосу пропускания. Лучшим подходом, чем «подход к корневому каталогу» для разрешения www.google.com, будет настройка сервера пересылки. Сервер пересылки — это сервер имен, который обрабатывает запросы имен, которые не могут быть разрешены другим сервером имен. Давайте посмотрим, как работает описанный выше сценарий, когда сервер пересылки настроен на внутреннем сервере имен SRV210:

1. DESK231 отправляет повторный запрос SRV220 с просьбой преобразовать www.google.com в связанный с ним IP-адрес.
2. SRV220 просматривает свою базу данных DNS и находит информацию о зоне только для домена test2003.local, понимает, что www.google.com не является частью этого домена, и решает, что не знает, как преобразовать www.google.com в IP-адрес., и проверяет свой список серверов пересылки, чтобы узнать, настроены ли для него какие-либо серверы пересылки.
3. В списке серверов пересылки он находит IP-адрес внешнего сервера имен, размещенного у интернет-провайдера компании, поэтому он перенаправляет запрос на сервер имен провайдера для обработки.
4. Сервер имен провайдера при необходимости обращается к корню (что может включать два или более дополнительных запроса), чтобы преобразовать www.google.com в свой IP-адрес и вернуть этот адрес в SRV220.
5. SRV220 возвращает адрес Бобу, и он видит, что Google появляется в его браузере.

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

В Windows 2000 серверы пересылки настраиваются с помощью вкладки «Общие» листа свойств DNS-сервера в консоли DNS:

Что отличается в Windows Server 2003, так это концепция условной переадресации, которую я рассмотрю далее.

Что делает условная переадресация

Условный сервер пересылки обрабатывает разрешение имен только для определенного домена. Например, вы можете настроить сервер имен для перенаправления любых запросов для хостов в домене google.com непосредственно на определенный сервер имен, который является полномочным для домена google.com. Что это делает, так это ускоряет процесс разрешения имен, устраняя необходимость обращаться к root, чтобы найти этот авторитетный сервер. В этом случае наш предыдущий пример теперь будет выглядеть так:

1. DESK231 отправляет повторный запрос SRV220 с просьбой преобразовать www.google.com в связанный с ним IP-адрес.
2. SRV220 просматривает свою базу данных DNS и находит информацию о зоне только для домена test2003.local, понимает, что www.google.com не является частью этого домена, и решает, что не знает, как преобразовать www.google.com в IP-адрес., и проверяет свой список серверов пересылки, чтобы узнать, настроены ли для него какие-либо серверы пересылки.
3. В списке серверов пересылки он находит настроенный условный сервер пересылки, который указывает IP-адрес авторитетного сервера имен для домена google.com, поэтому он перенаправляет запрос на этот сервер имен для его обработки.
4. Сервер имен google.com немедленно преобразует www.google.com в свой IP-адрес без необходимости обращения к корневому каталогу и возвращает этот адрес в SRV220.
5. SRV220 возвращает адрес Бобу, и Google быстро появляется в его браузере, побуждая Боба сказать: «Эй, сеть сегодня очень быстрая!»

Давайте теперь посмотрим, как настроить это в Windows Server 2003 DNS.

Как настроить условную переадресацию

Сначала давайте найдем полномочный сервер имен для домена google.com. Для этого мы воспользуемся инструментом поиска WHOIS на веб-сайте NetworkSolutions по адресу http://www.networksolutions.com/en_US/whois/index.jhtml. Перейдите на эту страницу, введите google.com в поле поиска WHOIS, введите отображаемый код (функция, предотвращающая массовый поиск автоматическими программами), и отобразятся следующие результаты:

google.com

Whois-сервер версии 1.

Теперь можно регистрировать доменные имена в доменах.com и.net.
со многими различными конкурирующими регистраторами. Зайдите на http://www.internic.net
для получения подробной информации.



Имя домена: GOOGLE.COM
Регистратор: ALLDOMAINS.COM INC.
Whois-сервер: whois.alldomains.com
Реферальный URL: http://www.alldomains.com
Сервер имен: NS2.GOOGLE.COM
Сервер имен: NS1.GOOGLE.COM
Сервер имен: NS3.GOOGLE.COM
Сервер имен: NS4.GOOGLE.COM
Статус: РЕГИСТРАЦИЯ-БЛОКИРОВКА
Дата обновления: 3 октября 2002 г.
Дата создания: 15 сентября 1997 г.
Срок годности: 14 сентября 2011 г.












Узнаем IP-адрес сервера имен NS1.GOOGLE.COM с помощью ping:

Теперь, когда у нас есть IP-адрес одного из серверов имен, уполномоченных для домена google.com, мы можем настроить DNS Windows Server 2003 для условной пересылки всех запросов имен для этого домена на этот сервер имен.

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

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

Нажмите OK, и новый домен появится в верхнем списке (убедитесь, что он выбран для следующего шага):

Теперь введите IP-адрес вашего условного сервера пересылки в пунктирное поле и нажмите «Добавить», чтобы добавить его в список серверов пересылки выбранного домена:

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

Использование условной переадресации

Когда в реальном мире вам может понадобиться использовать условную переадресацию? Я могу придумать несколько ситуаций, когда это может быть полезно:

• Чтобы улучшить разрешение имен между двумя отдельными компаниями, которым необходимо предоставить своим пользователям доступ к ресурсам в интрасети другой компании. Такого рода ситуации распространены в ситуации слияния или между партнерами по цепочке поставок. Просто настройте DNS-серверы в каждой компании для перенаправления запросов имен для ресурсов в сети другой компании непосредственно на IP-адреса серверов имен в другой компании, и все готово. Конечно, это также можно сделать с помощью зон-заглушек, как я обсуждал в своей предыдущей статье «Зоны-заглушки DNS в Windows Server 2003», и я сравню два подхода через мгновение.
• Чтобы улучшить разрешение имен в реализации Active Directory с несвязанным пространством имен (отдельные леса или несколько деревьев доменов) или глубокой иерархией поддоменов. В такой ситуации вы можете настроить условную переадресацию, чтобы пользователям в одном домене не приходилось проходить весь путь до root для поиска ресурсов в отдельном лесу, другом дереве доменов или вниз по иерархии доменов в дереве. Опять же, при желании для этой цели можно использовать тупиковые зоны.
• А затем он используется просто для переадресации запросов имен для определенных интернет-сайтов, таких как google.com, как в приведенном выше примере, но этот пример предназначен только для иллюстрации процедуры настройки условной переадресации на вашем сервере имен — у моей компании нет планов о слиянии с Google в ближайшее время.

Резюме

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

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