Возможности DNS в Windows Server 2008 и Vista, а также обновленных Windows XP и Windows Server 2003 приближают нас к миру без WINS.
Опыт освоения двух последних, значительно обновленных версий Windows Server приучил нас к мысли о том, что в новых релизах появляются изменения, которые касаются в первую очередь разрешения имен и службы именования DNS. В этом смысле не стала исключением и версия Windows Server 2008.
Чтобы наконец-то дать новым пользователям возможность работать в свободных от службы WINS сетях, разработчики допустили использование сугубо локальной версии DNS. Они реализовали зону DNS, которая в какой-то степени замещает службу WINS, и внесли два усовершенствования в процесс поиска системами Windows контроллеров доменов, DC. Но перед тем как мы перейдем к деталям, вам следует задать себе вопрос: «Нужна ли мне служба WINS?»
Любая дискуссия по проблемам разрешения имен Windows всегда начинается с вопроса: «Могу ли я сейчас отключить систему NetBIOS и службу WINS?». И ответ на него остается практически неизменным на протяжении вот уже девяти лет: в одних случаях это возможно, в других — нет. По сути дела, вам не обойтись без WINS, если для работы ваших операционных систем или приложений требуется NetBIOS.Если в сети используются Windows XP или Windows Server 2003, по линии операционной системы в большинстве случаев все будет в порядке (хотя в некоторых сетях NetBIOS все еще может понадобиться, как мы скоро увидим). Но если говорить о работающих в наших организациях приложениях, многие из них не могут обойтись без NetBIOS/WINS.
В отличие от других аспектов работы с сетями Windows, здесь мы имеем ситуацию, в которой многие малые и средние компании обычно с большей легкостью отказываются от службы WINS, нежели крупные предприятия. Сотрудники небольших компаний часто работают в одном здании, их настольные системы функционируют под управлением лишь Windows Vista или Windows XP, в служебных офисах используются только системы Windows Server 2008 или Windows 2003. Что же до приложений, то служащим таких компаний не требуется почти ничего, кроме Acrobat Reader, браузера IE и комплекта программ Office. Эта среда идеально подходит для работы без WINS и без NetBIOS по протоколам TCP/IP. А если говорить о крупных организациях, практически во всех, с которыми мне доводилось соприкасаться на протяжении моей практики консультанта, эксплуатируется набор старых приложений собственной разработки — приложений, которые не могут обойтись без службы WINS, и так будет всегда, пока кто-нибудь не перепишет эти приложения заново (или пока функции этой службы не сможет взять на себя новый продукт GlobalNames, но об этом позже).
Итак, можете ли вы отказаться от использования WINS? Единственная возможность получить гарантированно точный ответ состоит в том, чтобы тщательно протестировать ваши приложения в сети на основе Server 2008. Многие полагают, что для этого необходимо выполнить большой объем работ. Со своим вариантом ответа на вопрос, нужна WINS или нет, выступил разработчик Microsoft Тим Рейнс. В заметке «Why you still run Windows Internet Naming Service (WINS)», опубликованной в его блоге еще в 2004 году, Рейнс предложил интересующимся этим вопросом устанавливать на своих серверах WINS монитор производительности Performance Monitor (blogs.msdn.com/tim_rains/archive/2004/10/05/238236.aspx), который будет регистрировать частоту запросов на разрешение имен, направляемых в службу WINS. Возможно, самый простой ответ состоит в следующем. Нужно ежемесячно фиксировать максимальные результаты мониторинга производительности, а когда они начнут снижаться, всерьез рассмотреть вопрос об отключении службы WINS.
Замена сообщений NetBIOS
Если бы системы NetBIOS не существовало, возник бы один важный вопрос: как могут разрешаться имена в системах, находящихся в одной подсети, если они не внесены в DNS? Небольшие специальные сети, тестовые сети и классные сети иногда не оснащаются серверами DNS или просто не могут включать в себя такие серверы; например, почти нет таких домашних сетей, в которых имелась бы хотя бы одна копия Windows Server, а для Windows XP корпорация Microsoft вообще не выпускает службы DNS. В настоящее время во всех не имеющих службы DNS сетях разрешение имен осуществляется посредством рассылки широковещательных сообщений NetBIOS — весьма расточительно, это может занимать от 10 до 20 процентов полосы пропускания сети. А в сетях, состоящих из систем Server 2008 и Windows Vista, возможно локальное разрешение имен без рассылки широковещательных сообщений. Эта задача решается с помощью технологии Link-Local Multicast Name Resolution (LLMNR), как описано в документе RFC 4795 (tools.ietf.org/html/rfc4795).
LLMNR определяет группу многоадресной передачи по адресу 224.0.0.252, которую совместимые с LLMNR системы (т. е. Windows Vista и более новые версии — Microsoft еще не разработала модуль оперативной коррекции для систем Windows XP и Windows 2003) могут использовать для направления запросов по именам и получения в ответ IP-адресов. Так, запрос об IP-адресе системы с именем PC33 не направляется каждой системе сети, использующей IP-адрес, а передается тем системам, которые вошли в группу многоадресной передачи. Нетрудно догадаться, что для разрешения имен в таких обстоятельствах не требуется служба Computer Browser.
Однако достоинства LLMNR этим не ограничиваются. В отличие от широковещательных сообщений NetBIOS, запросы LLMNR дают возможность возвращать не только адреса IPv4, но и все адреса IPv6, имеющиеся в данной системе. А если вы полагаете, что для решения связанных с LLMNR проблем придется изучать какой-нибудь новый малоизвестный протокол, отбросьте опасения: запросы LLMNR представляют собой всего лишь хорошо известные стандартные запросы DNS. Кстати, о стандартах. Если вы работаете с аппаратными средствами Apple или Sun, вы, по-видимому, уже знакомы с аналогичным протоколом для этих платформ, обеспечивающим локальное разрешение имен без сервера DNS. Это протокол multicast DNS (mDNS). По принципам действия LLMNR напоминает mDNS (и я, честно говоря, не совсем понимаю, почему специалисты Microsoft не использовали разработанный семь лет назад mDNS).
Значение функции Network Discovery
Задача средств DNS, LLMNR и NetBIOS не ограничивается исключительно разрешением имен. Во многих случаях мы преобразуем имя сервера в соответствующий адрес для того, чтобы определить, какие службы предлагает этот сервер, как именуются его файловые ресурсы общего доступа и общие ресурсы печати, какие Web-службы на нем установлены и т. д. Таким образом, разрешение имен тесно связано с более широкой (и более важной) темой обнаружения ресурсов.
В конце 1980-х годов корпорация Microsoft предоставила пользователям сетей LAN Manager возможность получать список серверов сети и запрашивать у этих серверов списки их ресурсов общего доступа. Это была, если можно так выразиться, версия 1.0 продукта Microsoft Resource Discovery, и была она исключительно примитивной. Пользователь должен был выдвинуть предположение относительно того, на каком сервере расположен интересующий его ресурс, а затем просмотреть ресурсы сервера, дабы убедиться в том, что его предположение верно. Позднее в Windows 2000 была реализована идея публикации файловых ресурсов общего доступа и общих ресурсов печати в службе Active Directory (AD) с полным набором средств для указания ключевых слов и поиска. К сожалению, я знаю мало организаций, использующих метод публикации ресурсов.
В системах Server 2008 и Windows Vista, а также в какой-то степени и в Windows XP, Microsoft «обкатывает» новый подход к проблеме обнаружения ресурсов: с помощью средства Network Discovery, которое представляет собой не отдельный протокол, а коллекцию протоколов. При использовании Network Discovery ваша система с целью составления перечня других локальных систем может применять как Computer Browser на основе NetBIOS, так и систему групповой передачи на базе LLMNR. Но для обнаружения ресурсов (скажем, для выяснения того, кто участвует в использовании цветного принтера или кто является владельцем ресурса, связанного с годовым отчетом) системы Server 2008, Windows Vista и Windows XP, если на них установлен пакет обновлений SP3 и оперативный модуль коррекции, описанный в статье Microsoft «Network Map in Windows Vista does not display computers that are running Windows XP» (support.microsoft.com/kb/922120), допускают использование протокола обнаружения Web-служб, а именно Web Services Discovery (WSD). По сути, WSD можно определить как следующее поколение упрощенного протокола обнаружения служб Simplified Services Discovery Protocol (SSDP) и технологии Universal Plug and Play (UPnP), но оснащенное средствами защиты.
WSD — еще один способ, обеспечивающий равноправным системам в сети возможность рекламировать свои функции. Идея состоит в том, что любая система, которой требуется, к примеру, общедоступный принтер, может искать таковой, направляя запросы другим системам по сетевым каналам методом групповой рассылки. Подобным же образом система может направить сообщение в адрес другой системы с запросом, использует ли последняя принтер общего доступа. Нет, это не схема клиент-сервер, подобная той, что реализована при публикации в AD. Предполагается, что рассматриваемый метод будет в большей степени опираться на стандарты, нежели браузеры NetBIOS, поскольку он реализуется поверх всех Web-служб, протокола Simple Object Access Protocol (SOAP) и т. п. Один из типов сетевого трафика по обнаружению Web-служб можно распознать, когда появятся сообщения UDP, направляемые на порт 3702 по групповому адресу 239.255.255.250. Эти сообщения, а они представляют собой текст XML, отформатированный по стандарту SOAP, являются запросами общего назначения на предоставление шлюза для соединения с Internet. Кроме того, вы увидите сообщения TCP, направляемые конкретным серверам на порт 5357 или на порт 5358 (один из них — порт HTTP, а другой — порт HTTPS), в зависимости от того, чем завершается аутентификация клиента на сервере; эти сообщения называются направленными сообщениями обнаружения, directed discovery messages, потому что система опрашивает не группу серверов, а один конкретный сервер.
Какие системы могут участвовать в операциях Network Discovery и WSD? Понятно, что к таким системам относятся Server 2008, Windows Vista и более новые версии. В какой-то мере в этих операциях могут участвовать и системы Windows XP, но только если на всех системах включен протокол NetBIOS over TCP, а также при условии установки пакета обновлений SP3 и оперативного модуля коррекции из ранее упомянутой статьи Microsoft.
Изменения в DNS на стороне клиента
Некоторые наиболее важные изменения в сфере DNS, внесенные в систему Server 2008, реализованы не в серверном компоненте DNS, а в клиентских модулях DNS. В службе AD рядовые системы должны прежде всего, обнаружить контроллер домена, и только после этого они могут зарегистрироваться в домене. Для решения данной проблемы клиентская система использует DNS и, обнаружив контроллер домена, продолжает задействовать только этот контроллер для проведения аутентификации в будущем до тех пор, пока не будет перезагружена (если речь идет о системе, входящей в AD, но выпущенной до появления Windows Vista).
Обычно этих функций вполне достаточно для решения поставленной задачи, но в некоторых случаях первоначально обнаруженный системой контроллер домена оказывается удаленным, и вследствие низкой производительности канала связи между системой и контроллером замедляется процесс аутентификации; эта проблема сохраняется до тех пор, пока система не будет перезагружена или пока кто-нибудь не обратит внимания на снижение быстродействия и с помощью команды Netdom Reset не заставит систему отыскать новый (и предположительно расположенный ближе) контроллер домена.
Но, работая под управлением Server 2008, Vista, Windows XP или Windows 2003 (на двух последних должен быть установлен модуль оперативной коррекции), система уже не остается «привязанной» к данному контроллеру домена до перезагрузки. Она помнит текущий «партнерский» контроллер в течение 12 часов, после чего, если ей будет нужен контроллер и в дальнейшем, вновь направляет DNS соответствующий запрос. Вы можете модифицировать эту схему, удлиняя или укорачивая интервал времени. Перейдите в раздел реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\ Parameters, создайте запись REG_DWORD с именем ForceRediscoveryInterval и установите интервал времени в секундах. Это удобная функция, но опять-таки подчеркну, что для ее использования в среде Windows XP и Windows 2003 нужно будет установить вышеупомянутый модуль оперативной коррекции.
Это не единственная хорошая новость для тех, кто хотел бы, чтобы рядовые системы всегда могли обнаруживать именно близлежащие контроллеры доменов. В системы Server 2008 и Windows Vista было внесено еще одно изменение, касающееся реализованного на клиентской стороне механизма DNS по обнаружению контроллеров домена. Направляя в DNS запрос с целью обнаружения контроллеров домена, клиенты AD систем Windows 2000 и более поздних версий запрашивают у DNS два списка контроллеров доменов. Сначала они обращаются к DNS с запросом о предоставлении списка контроллеров домена у них на узле. Если клиентская система просит все локальные контроллеры домена зарегистрировать ее, но ни один контроллер в течение 400 миллисекунд не отвечает, система запрашивает у DNS второй список — список всех контроллеров доменов на всех узлах, и тогда эта система предлагает каждому из упомянутых контроллеров домена зарегистрировать ее. Вот почему вас иногда регистрирует контроллер домена в Вашингтоне, тогда как вы находитесь в городе Остин, штат Техас.
Те, кто работает с Server 2008 и Windows Vista, могут при желании изменить порядок поиска контроллера домена членами AD.Если ваши системы опросили все локальные контроллеры и не получили ответа, вы можете предписать своим клиентским системам далее обратиться к DNS не за списком контроллеров доменов, расположенных по всему миру, а за перечнем контроллеров с ближайшего узла (каковой определяется через сумму расходов на соединение с этим узлом). Такой алгоритм не применяется по умолчанию; чтобы задействовать его, перейдите в раздел реестра
HKEY_LOCAL_MACHINE\SYSTEM\Current ControlSet\Services\Netlogon\Parameters,
создайте параметр типа REG_DWORD с именем TryNextClosestSite, приравняйте его к 1 и перезагрузите систему. Или используйте настройку Group Policy в разделе
Computer Configuration\Administrative Templates\System\Netlogon\DC Locator DNS Records\Try Next Closest Site.
К сожалению, в системах Windows XP или Windows 2003 такой возможности нет.
Зона GlobalNames
В Microsoft знают, что многим пользователям приходится работать со старыми, NetBIOS-ориентированными приложениями, которые они не смогут заменить в обозримом будущем новыми, и что многие из них очень хотят избавиться от протокола NetBIOS, как только это будет возможно. Для таких клиентов DNS системы Server 2008 предлагает свой вариант ответа — зона GlobalNames.
Идея состоит в том, что многие «завязанные» на NetBIOS системы могут прекрасно обходиться без службы WINS, если только в эти приложения будут передаваться короткие имена серверов. Дайте команду одному из таких приложений вступить во взаимодействие с сервером server44.bigfirm.com, и оно начнет жаловаться; но стоит настроить приложение на имя server44 — и все будет в порядке. Опять-таки нужно сказать, что этот метод не решает проблемы всех старых приложений, но он годится для многих из них, и эти-то приложения и являются целевыми для GlobalNames.
Возможно, вы знаете, почему в приложениях, не оснащенных средствами для взаимодействия с DNS, можно применять имя хост системы. Ваша клиентская операционная система настроена с DNS-суффиксом, таким, например, как bigfirm.com. Когда несовместимое с DNS приложение предлагает клиентской операционной системе разрешить имя server44, служба DNS клиента автоматически дополняет имя системы этим DNS-суффиксом и предлагает своему серверу DNS разрешить полное доменное имя, в данном случае server44.bigfirm.com. Служба DNS может обрабатывать подобные имена; она возвращает соответствующий IP-адрес, и старое приложение получает то, что ему требовалось.
В этом состоит одна из причин, позволяющих лесам, состоящим из одного домена, с большей вероятностью отказываться от службы WINS и обходиться при этом без зоны GlobalNames — проблема этих лесов прекрасно решается силами клиентских агентов DNS. Ну а если сеть предприятия состоит из двух или большего числа доменов? Представим себе, что наш клиент имеет DNS-суффикс mmco.com, а система server44 имеет суффикс bigfirm.com. В этом случае гарантии того, что система server44 и пытающийся обратиться к ней клиент находятся в одном домене, дать нельзя, поэтому разрешение имен не сработает. Разумеется, вы можете с помощью групповой политики развернуть целый ряд DNS-суффиксов, но, по всей видимости, значительное число пользователей продуктов Microsoft сочли, что такой системой трудно управлять, и вот на свет появилась зона GlobalNames.
Серверы DNS на базе системы Server 2008, сконфигурированные соответствующим образом, могут содержать особую зону GlobalNames, однокомпонентное имя в отличие от получивших более широкое распространение двухкомпонентных имен, таких как bigfirm.com. Получив предписание разрешить имя server44, наш гипотетический клиент добавит к нему суффикс mmco.com и направит службе DNS запрос на разрешение имени server44.mmco.com; понятно, что такое имя найдено не будет. Но DNS-сервер системы Server 2008, сконфигурированный для использования зоны GlobalNames, на этом не остановится. Он возьмет имя хост-системы (server44) и обратится к зоне GlobalNames в поисках этого однокомпонентного имени. Важная особенность зоны GlobalNames состоит в том, что она может включать в себя только записи типа CNAME (псевдонимы) — записи, которые вы создали статически. Если какая-либо из записей CNAME соответствует имени server44, сервер DNS обращается к целевой системе из записи CNAME — например, к server44.bigfirm.com — и запрашивает ее запись A. Этот запрос будет выполнен успешно; мы уже определили, что имя server44.bigfirm.com существует, так что DNS-сервер системы Server 2008 возвратит клиенту соответствующий IP-адрес, и старое приложение получит то, что ему требуется.
Установка зоны GlobalNames выполняется довольно просто; правда, она связана с определенными ограничениями. Прежде всего, все серверы DNS в вашей корпоративной сети должны работать под управлением системы Server 2008, ибо только эта система оснащена достаточно интеллектуальным DNS-сервером, способным удалить старый суффикс и найти запись CNAME; если клиент обратится с запросом к какому-либо другому DNS-серверу, результат будет отрицательным. Во-вторых, вам, вероятно, будет проще всего управлять зоной GlobalNames, если вы интегрируете ее в AD и разместите в разделе ForestDNS. По умолчанию DNS-серверы Server 2008 не знают, как использовать GlobalNames, — до тех пор пока вы не введете следующую команду (это нужно сделать на каждом сервере DNS):
dnscmd/config/ Enableglobalnamessupport 1
Реализованные в службе DNS системы Server 2008 средства для работы с зоной GlobalNames имеют еще один (недокументированный) недостаток: они определяют DNS-суффикс клиента, направляющего запрос о разрешении имени, и, если этот DNS-суффикс не соответствует ни одной из зон, за которую несет ответственность данный DNS-сервер, этот сервер так и не обращается к зоне GlobalNames (о чем свидетельствует мой опыт).
Заслуживает внимания
Если вы уже развертываете системы Windows Vista и Server 2008, присмотритесь к их средствам для разрешения имен. Вы поймете, как эти средства влияют на внутренние механизмы функционирования сетей. Вполне возможно, что зона GlobalNames облегчит вашу работу со старыми приложениями. А если вы все еще эксплуатируете системы Windows XP или Windows 2003, не оставляйте без внимания их факультативные модули обновления. Разработчики этих систем не хотят оставаться в стороне от общей тенденции снижения нагрузки на каналы связи.
Марк Минаси — редактор Windows IT Pro, MCSE и автор книги Mastering Windows Server 2003 (издательство Sybex)
Журнал «Windows IT Pro», Издательство «Открытые системы» (http://www.osp.ru/)