Разрешение имен в сетях Windows Server 2008
Механизм, посредством которого имена NetBIOS разрешаются в IP-адреса, зависит от типа узла NetBIOS, отконфигурированного для компьютера.
Основные преимущества NetBIOS как механизма разрешения имен в том, что вначале протокол NetBIOS по умолчанию разрешает имена соседних компьютеров, не требуя конфигурации, и он включен во все версии Windows. Кроме того, при добавлении WINS-сервера в инфраструктуру разрешения имен NetBIOS можно использовать (аналогично DNS и в отличие от LLMNR) для разрешения имен компьютеров в соседних подсетях. (В частности, эта возможность используется в случае, когда удаленные компьютеры не зарегистрированы в DNS-зоне.) Другие преимущества NetBIOS заключаются в том, что конфигурировать и управлять NetBIOS легче, чем DNS, и в отличие от LLMNR протокол NetBIOS работает в IPv4-узлах.
Записи ресурсов представляют сущности базы данных DNS, которые используются для ответов на запросы клиентов DNS. Каждый DNS-сервер содержит записи ресурсов, которые использует для ответов на запросы своей части пространства имен DNS. Каждая запись ресурсов описана с конкретным типом ресурса, например адрес (А) IPv4-yзлa, адрес (АААА) IPv6-узла, псевдоним (CNAME), указатель (PTR) и почтовый обменщик MX (Mail eXchanger). Эти записи подробно описаны в теме 1 главы 3.
Запрос DNS
Пример запроса
Кэширование поддерживают обе службы — DNS-клиент и DNS-сервер. Кэширование повышает производительность DNS и значительно снижает уровень трафика запросов DNS в сети.
Кэш DNS-клиента
Кэш DNS-клиента еще называют кэшем распознавателя DNS. При каждом запуске службы DNS-клиент все сопоставления имен в IP-адреса, содержащиеся в статическом файле Hosts, предварительно загружаются в кэш распознавателя DNS. Файл Hosts находится в папке WINDOWS\System32\Drivers\Etc.
ПРИМЕЧАНИЕ: Использование файла Hosts
Каждая запись, добавляемая в файл Hosts, немедленно загружается в кэш распознавателя DNS.
Помимо записей в файле Hosts кэш распознавателя DNS также включает записи, получаемые клиентом в ответ на запросы DNS-серверов. Каждый раз при остановке службы DNS-клиент (DNS Client) выполняется очистка кэша распознавателя DNS.
Кэш DNS-сервера
При подключении к компьютеру обычно указывается такое имя, как www.microsoft.com или FileSrvB. Однако такие компьютерные имена используются лишь для удобства пользователей. Для подключения к удаленному компьютеру имя должно быть преобразовано в IP-адрес, по которому будет выполняться маршрутизация пакетов. В компьютерной терминологии DNS, или разрешение имени, компьютера означает его преобразование в адрес, а сам процесс такого преобразования называется разрешением имен (DNS).
Разрешение имен является одним из самых важных компонентов сетевой инфраструктуры. Системный администратор Windows должен понимать принцип разрешения имен для настройки и устранения неполадок этого компонента.
Разрешение имен является одним из самых важных компонентов сетевой инфраструктуры. Системный администратор Windows должен понимать принцип разрешения имен для настройки и устранения неполадок этого компонента.
Методы разрешения имен в Windows
Сети Windows Server 2008 включают не меньше трех систем разрешения имен: DNS, LLMNR (Link Local Multicast Name Resolution) и NetBIOS. Самой важной является DNS, поскольку этот метод разрешения имен используется для поддержки служб доменов Active Directory (Active Directory Domain Services) и разрешения всех имен Интернета. Таким образом, DNS — наиболее предпочтительный метод разрешения имен в Windows, который по возможности используется во всех ситуациях.
Тем не менее, самой системы DNS недостаточно для разрешения имен во всех сетях Windows. Инфраструктура DNS требует настройки сетевой конфигурации на серверах и клиентах. Такой инфраструктуры DNS нет в небольших и неофициальных сетях. Поэтому, к примеру, DNS нельзя использовать для разрешения имен компьютеров в рабочей группе, на которых система Windows Server 2008 установлена с параметрами по умолчанию. В таких рабочих группах используются другие службы разрешения имен — LLMNR и NetBIOS. В следующем подразделе описаны резервные механизмы разрешения имен.
Тем не менее, самой системы DNS недостаточно для разрешения имен во всех сетях Windows. Инфраструктура DNS требует настройки сетевой конфигурации на серверах и клиентах. Такой инфраструктуры DNS нет в небольших и неофициальных сетях. Поэтому, к примеру, DNS нельзя использовать для разрешения имен компьютеров в рабочей группе, на которых система Windows Server 2008 установлена с параметрами по умолчанию. В таких рабочих группах используются другие службы разрешения имен — LLMNR и NetBIOS. В следующем подразделе описаны резервные механизмы разрешения имен.
Link Local Multicast Name Resolution
Метод разрешения имен Link Local Multicast Name Resolution (LLMNR) используется функцией Сетевое обнаружение (Network Discovery), которую можно включить в Центре управления сетями и общим доступом (Network And Sharing Center), представленном на рисунке ниже. Протокол LLMNR применяется только в системах Windows Vista и Windows Server 2008.
Метод LLMNR использует многоадресное вещание для разрешения IPv6- адресов компьютеров лишь в локальной подсети. Протокол LLMNR является более предпочтительным методом разрешения имен, чем NetBIOS. Поэтому LLMNR используется для отдельной подсети без инфраструктуры DNS, содержащей лишь компьютеры Windows Vista и Windows Server 2008, на которых включен протокол IPv6 и Сетевое обнаружение (Network Discovery).
Предположим, на вашем компьютере ClientA установлена система Windows Vista, включен протокол IPv6 и Сетевое обнаружение (Network Discovery). Если вы захотите подключиться к компьютеру ClientB, указав UNC-путь (Universal Naming Convention) в виде \\ClientB в сети без DNS, ваш компьютер для разрешения имени ClientB сначала использует LLMNR.
Метод LLMNR использует многоадресное вещание для разрешения IPv6- адресов компьютеров лишь в локальной подсети. Протокол LLMNR является более предпочтительным методом разрешения имен, чем NetBIOS. Поэтому LLMNR используется для отдельной подсети без инфраструктуры DNS, содержащей лишь компьютеры Windows Vista и Windows Server 2008, на которых включен протокол IPv6 и Сетевое обнаружение (Network Discovery).
Предположим, на вашем компьютере ClientA установлена система Windows Vista, включен протокол IPv6 и Сетевое обнаружение (Network Discovery). Если вы захотите подключиться к компьютеру ClientB, указав UNC-путь (Universal Naming Convention) в виде \\ClientB в сети без DNS, ваш компьютер для разрешения имени ClientB сначала использует LLMNR.
Компьютер ClientA использует для разрешения этого имени метод LLMNR, проверив сначала в кэше LLMNR локального компьютера ранее разрешенные имена. Если соответствующая запись не найдена, ClientA через IPv6 отправит LLMNR-запрос имени (Name Query Request) на широковещательный (Multicast) адрес FF02::1:3. Все IPv6-yзлы в сети с включенным сетевым обнаружением прослушивают трафик, пересылаемый на этот широковещательный адрес. Если ClientB с включенным сетевым обнаружением расположен в той же подсети, компьютер отреагирует на запрос и перешлет на компьютер ClientA свой IPv6- адрес. После этого ClientA сможет установить соединение с машиной ClientB. Описываемый процесс продемонстрирован ниже.
ПРИМЕЧАНИЕ: Протокол LLMNR в IPv4
Протокол LLMNR также отправляет запросы разрешения имен в IPv4 (в частности, по адресу 224.0.0.252), однако во время написания этой книги клиенты Windows Server 2008 и Windows Vista по умолчанию не отвечали на эти запросы.
В качестве механизма разрешения имен LLMNR обеспечивает несколько важных преимуществ. Во-первых, для разрешения имен компьютеров в локальной подсети не требуется конфигурация. Во-вторых, в отличие от NetBIOS метод LLMNR совместим с IPv6. Таким образом, LLMNR является единственным протоколом разрешения имен, который работает без конфигурации в IPv6- сетях Windows. В-третьих, по сравнению с NetBIOS метод LLMNR компактней и, следовательно, имеет меньший фронт атаки.
ПРИМЕЧАНИЕ: Протокол LLMNR в IPv4
Протокол LLMNR также отправляет запросы разрешения имен в IPv4 (в частности, по адресу 224.0.0.252), однако во время написания этой книги клиенты Windows Server 2008 и Windows Vista по умолчанию не отвечали на эти запросы.
В качестве механизма разрешения имен LLMNR обеспечивает несколько важных преимуществ. Во-первых, для разрешения имен компьютеров в локальной подсети не требуется конфигурация. Во-вторых, в отличие от NetBIOS метод LLMNR совместим с IPv6. Таким образом, LLMNR является единственным протоколом разрешения имен, который работает без конфигурации в IPv6- сетях Windows. В-третьих, по сравнению с NetBIOS метод LLMNR компактней и, следовательно, имеет меньший фронт атаки.
Однако LLMNR имеет и множество недостатков, в частности этот метод не разрешает имена компьютеров с системами Windows Server 2003, Windows XP и другими предыдущими версиями Windows. Кроме того, LLMNR не позволяет устанавливать соединения с клиентами в lPv4-сети Windows. Более того, для работы LLMNR на всех компьютерах в подсети нужно включить сетевое обнаружение, то есть, даже не требуя конфигурирования, этот протокол не разрешает имена компьютеров по умолчанию. Но самый значительный недостаток LLMNR заключается в том, что этот протокол нельзя использовать для разрешения имен компьютеров за пределами локальной подсети.
ПРИМЕЧАНИЕ: Отключение LLMNR в сети
Протокол LLMNR можно отключить сразу для большого числа компьютеров с помощью групповой политики. В объекте групповой политики (Group Policy Object, GPO) откройте папку Конфигурация компьютера\Административные шаблоны\Сеть\DNS-клиент (Computer Configuration\Administrative Templates\Network\DNS Client) и найдите параметр политики Отключить многоадресное разрешение имен (Turn Off Multicast Name Resolution).
ПРИМЕЧАНИЕ: Отключение LLMNR в сети
Протокол LLMNR можно отключить сразу для большого числа компьютеров с помощью групповой политики. В объекте групповой политики (Group Policy Object, GPO) откройте папку Конфигурация компьютера\Административные шаблоны\Сеть\DNS-клиент (Computer Configuration\Administrative Templates\Network\DNS Client) и найдите параметр политики Отключить многоадресное разрешение имен (Turn Off Multicast Name Resolution).
Разрешение имен NetBIOS
Устаревший протокол и система именования NetBIOS или NetBIOS через TCP/IP (NetBT или NBT) используется для обеспечения совместимости со старыми сетевыми службами Windows. Хотя NetBIOS в определенных ситуациях можно отключить, сетевой администратор должен уметь конфигурировать, управлять и устранять неполадки разрешения имен NetBIOS.
Протокол NetBIOS по умолчанию обеспечивает разрешение имен в IPv4- сетях Windows без DNS. Например, в домашней беспроводной сети можно подключаться к другим компьютерам, указывая их имена UNC (\\Comp3), не включая Сетевое обнаружение (Network Discovery), даже если на машине CompЗ установлена операционная система Windows XP. Протокол NetBIOS также позволяет проверить имя CompЗ с помощью команды ping и получить ответ с IPv4-адреса этого компьютера. система Windows всегда будет вначале пытаться разрешить имя с помощью DNS, а в случае недоступности DNS попытается использовать LLMNR и NetBIOS. В данном случае понятно, что для разрешения имени система Windows использует NetBIOS, поскольку в имя компьютера не включен домен DNS (например, mydomain.com) и ответ на запрос пришел с IPv4-адреса. (Ответ с IPv4-адреса означает использование LLMNR).
Протокол NetBIOS по умолчанию обеспечивает разрешение имен в IPv4- сетях Windows без DNS. Например, в домашней беспроводной сети можно подключаться к другим компьютерам, указывая их имена UNC (\\Comp3), не включая Сетевое обнаружение (Network Discovery), даже если на машине CompЗ установлена операционная система Windows XP. Протокол NetBIOS также позволяет проверить имя CompЗ с помощью команды ping и получить ответ с IPv4-адреса этого компьютера. система Windows всегда будет вначале пытаться разрешить имя с помощью DNS, а в случае недоступности DNS попытается использовать LLMNR и NetBIOS. В данном случае понятно, что для разрешения имени система Windows использует NetBIOS, поскольку в имя компьютера не включен домен DNS (например, mydomain.com) и ответ на запрос пришел с IPv4-адреса. (Ответ с IPv4-адреса означает использование LLMNR).
Методы разрешения имен NetBIOS
Протокол NetBIOS включает три метода разрешения имен: широковещание, WINS и файл Lmhosts.
■ Широковещание NetBIOS
Такой метод разрешения имен NetBIOS заключается в широковещании через IPv4. Для подключений по локальной сети в Windows протокол NetBIOS включен по умолчанию. Таким образом, компьютер, которому требуется разрешить имя, выполняет широковещательный запрос IPv4-адреса собственника имени в локальной сети.
■ WINS-сервер
По сути, WINS-сервер представляет каталог таких имен компьютеров, как Client2 и ServerB, и связанные с ними IP-адреса. При настройке сетевого подключения с адресом WINS-сервера выполняются два действия. Во-первых, вы разрешаете компьютеру выполнять поиск компьютерных имен, которые нельзя разрешить с помощью DNS или LLMNR. Во- вторых, вы регистрируете имя локального компьютера в каталоге WINS- сервера. Главное преимущество WINS состоит в том, что WINS-сервер включает разрешение имен NetBIOS за пределами локальной подсети.
Такой метод разрешения имен NetBIOS заключается в широковещании через IPv4. Для подключений по локальной сети в Windows протокол NetBIOS включен по умолчанию. Таким образом, компьютер, которому требуется разрешить имя, выполняет широковещательный запрос IPv4-адреса собственника имени в локальной сети.
■ WINS-сервер
По сути, WINS-сервер представляет каталог таких имен компьютеров, как Client2 и ServerB, и связанные с ними IP-адреса. При настройке сетевого подключения с адресом WINS-сервера выполняются два действия. Во-первых, вы разрешаете компьютеру выполнять поиск компьютерных имен, которые нельзя разрешить с помощью DNS или LLMNR. Во- вторых, вы регистрируете имя локального компьютера в каталоге WINS- сервера. Главное преимущество WINS состоит в том, что WINS-сервер включает разрешение имен NetBIOS за пределами локальной подсети.
■ Файл Lmhosts
Статический файл локальной базы данных, который хранится в папке %SystemRoot%\System32\Drivers\Etc и сопоставляет конкретные имена NetBIOS адресам IP. Запись имени NetBIOS и связанного IP-адреса в файл Lmhosts позволяет компьютеру разрешать IP-адрес для данного имени NetBIOS в случае сбоя другого метода разрешения имен. Файл Lmhosts требуется создать вручную. Поэтому он обычно используется с целью разрешения имен удаленных клиентов, для которых недоступны другие методы разрешения имен — например, когда в сети нет WINS-сервера, удаленный клиент не зарегистрирован с помощью DNS-сервера или когда клиентский компьютер расположен за пределами диапазона широковещания.
Статический файл локальной базы данных, который хранится в папке %SystemRoot%\System32\Drivers\Etc и сопоставляет конкретные имена NetBIOS адресам IP. Запись имени NetBIOS и связанного IP-адреса в файл Lmhosts позволяет компьютеру разрешать IP-адрес для данного имени NetBIOS в случае сбоя другого метода разрешения имен. Файл Lmhosts требуется создать вручную. Поэтому он обычно используется с целью разрешения имен удаленных клиентов, для которых недоступны другие методы разрешения имен — например, когда в сети нет WINS-сервера, удаленный клиент не зарегистрирован с помощью DNS-сервера или когда клиентский компьютер расположен за пределами диапазона широковещания.
Включение и отключение NetBIOS
По умолчанию протокол NetBIOS включен для каждого подключения по локальной сети IPv4. Чтобы изменить параметры NetBIOS, откройте свойства подключения по локальной сети. Затем откройте свойства протокола Интернета версии 4 (TCP/IPv4) и щелкните кнопку Дополнительно (Advanced), чтобы открыть диалоговое окно Дополнительные параметры TCP/IP (Advanced TCP/ IP Settings). В этом диалоговом окне перейдите на вкладку Служба WINS (WINS).
Подключение по локальной сети по умолчанию разрешает WINS-серверу назначать параметры NetBIOS. Параметры NetBIOS, полученные с DHCP-сервера, не просто включают или отключают NetBIOS: DHCP-сервер может конфигурировать клиента в качестве конкретного типа узла NetBIOS.
Подключение по локальной сети по умолчанию разрешает WINS-серверу назначать параметры NetBIOS. Параметры NetBIOS, полученные с DHCP-сервера, не просто включают или отключают NetBIOS: DHCP-сервер может конфигурировать клиента в качестве конкретного типа узла NetBIOS.
Типы узлов NetBIOS
Механизм, посредством которого имена NetBIOS разрешаются в IP-адреса, зависит от типа узла NetBIOS, отконфигурированного для компьютера.
Существует четыре типа узлов.
■ Широковещательный (b-узел)
Этот тип узла использует широковещательные запросы имен NetBIOS для регистрации и разрешения имен. В-узел имеет два недостатка: широковещание затрагивает все узлы в сети, а маршрутизаторы, как правило, блокируют широковещание, так что разрешаться будут лишь имена NetBIOS в локальной сети. Принцип работы этого типа узлов больше других похож на LLMNR.
■ Узел точка-точка (р-узел)
Этот тип узла использует коммуникации точка- и WINS-сервер для разрешения имен. Р-узел не применяет широковещание, а напрямую запрашивает сервер имен.
■ Комбинированный (m-узел)
Данный тип узла вначале использует широковещание (b-узел), а затем, если имя не было разрешено с помощью широковещания, применяет запросы WINS-сервера (р-узел).
■ Смешанный (h-узел)
Этот тип узла вначале использует запросы WINS (р-узел), а затем — широковещание (b-узел), если сервер имен недоступен или имя не зарегистрировано в базе данных WINS. Однако до внедрения широковещания b-узла эти компьютеры также используют файл Lmhosts для поиска сопоставлений имени в IP-адрес. По умолчанию клиенты Windows конфигурируются с комбинированным, или h-узлом. Текущее состояние узла, назначенного компьютеру Windows, можно определить в результатах команды Ipconfig /all, как показано в примере. Отметим, что на этом компьютере назначен смешанный тип узла.
Преимущества и недостатки NetBIOS
■ Широковещательный (b-узел)
Этот тип узла использует широковещательные запросы имен NetBIOS для регистрации и разрешения имен. В-узел имеет два недостатка: широковещание затрагивает все узлы в сети, а маршрутизаторы, как правило, блокируют широковещание, так что разрешаться будут лишь имена NetBIOS в локальной сети. Принцип работы этого типа узлов больше других похож на LLMNR.
■ Узел точка-точка (р-узел)
Этот тип узла использует коммуникации точка- и WINS-сервер для разрешения имен. Р-узел не применяет широковещание, а напрямую запрашивает сервер имен.
■ Комбинированный (m-узел)
Данный тип узла вначале использует широковещание (b-узел), а затем, если имя не было разрешено с помощью широковещания, применяет запросы WINS-сервера (р-узел).
■ Смешанный (h-узел)
Этот тип узла вначале использует запросы WINS (р-узел), а затем — широковещание (b-узел), если сервер имен недоступен или имя не зарегистрировано в базе данных WINS. Однако до внедрения широковещания b-узла эти компьютеры также используют файл Lmhosts для поиска сопоставлений имени в IP-адрес. По умолчанию клиенты Windows конфигурируются с комбинированным, или h-узлом. Текущее состояние узла, назначенного компьютеру Windows, можно определить в результатах команды Ipconfig /all, как показано в примере. Отметим, что на этом компьютере назначен смешанный тип узла.
Преимущества и недостатки NetBIOS
Основные преимущества NetBIOS как механизма разрешения имен в том, что вначале протокол NetBIOS по умолчанию разрешает имена соседних компьютеров, не требуя конфигурации, и он включен во все версии Windows. Кроме того, при добавлении WINS-сервера в инфраструктуру разрешения имен NetBIOS можно использовать (аналогично DNS и в отличие от LLMNR) для разрешения имен компьютеров в соседних подсетях. (В частности, эта возможность используется в случае, когда удаленные компьютеры не зарегистрированы в DNS-зоне.) Другие преимущества NetBIOS заключаются в том, что конфигурировать и управлять NetBIOS легче, чем DNS, и в отличие от LLMNR протокол NetBIOS работает в IPv4-узлах.
Главное ограничение NetBIOS состоит в том, что, хотя этот протокол обеспечивает резервный метод разрешения имен компьютеров в пределах диапазона широковещания и небольших сетях, он неэффективен в больших сетях. В NetBIOS каждому компьютеру назначается только одно имя или метка. Если вы используете WINS для разрешения имен NetBIOS в подсетях, имя каждого компьютера должно быть уникальным для всей сети. Еще один недостаток NetBIOS состоит в том, что этот протокол не рекомендуется использовать в тех случаях, когда требуется высокий уровень безопасности. Система NetBIOS разглашает информацию о сетевых службах, которая может быть использована для взлома сети. И, наконец, протокол NetBIOS несовместим с IPv6-сетями.
ПРИМЕЧАНИЕ:
Если вы используете множество WINS-серверов в большой организации, па них нужно отконфигурировать репликацию, чтобы базы данных WINS все время обновлялись. В большинстве случаев на всех WINS-серверах настраивается репликация приема/передачи (push/pull) (особенно при звездообразной конфигурации), чтобы серверы могли эффективно обновлять друг друга.
Разрешение имен DNS
ПРИМЕЧАНИЕ:
Если вы используете множество WINS-серверов в большой организации, па них нужно отконфигурировать репликацию, чтобы базы данных WINS все время обновлялись. В большинстве случаев на всех WINS-серверах настраивается репликация приема/передачи (push/pull) (особенно при звездообразной конфигурации), чтобы серверы могли эффективно обновлять друг друга.
Разрешение имен DNS
Система DNS позволяет определять по имени компьютеры и другие ресурсы в Интернете. Обеспечивая иерархическую структуру и автоматизированный метод кэширования и разрешения имен узлов, DNS устраняет многие административные и организационные вопросы, связанные с именованием узлов в Интернете и больших частных сетях.
Именное пространство DNS
Система именования DNS основана на иерархической и логической древовидной структуре, которая называется пространством имен DNS. Это пространство имеет уникальный корень с любым количеством субдоменов. Каждый субдомен может располагать доменами нижнего уровня. Например, корень "" (пустая строка) в пространстве имен Интернета располагает множеством доменных имен верхнего уровня, одним из которых является org. Домен org может, например, содержать субдомен wikipedia.org компании Wikipedia, который, в свою очередь, может располагать производственным субдоменом ru.wikipedia.org. Организации также могут создавать частные сети и использовать собственное пространство имен DNS, скрытое для Интернета.
Доменные имена
Доменные имена
Каждый узел в доменном дереве DNS можно идентифицировать с помощью полного доменного имени FQDN (Fully Qualified Domain Name). Имя FQDN однозначно указывает расположение домена относительно корня доменного дерева DNS. Например, именем FQDN для сервера wiki в домене wikipedia.org будет wiki.wikipedia.org, представляющее конкатенацию имени узла (wiki) с основным DNS-суффиксом (wikipedia.org) и замыкающей точкой (.). Замыкающая точка является стандартным разделителем между меткой домена верхнего уровня и меткой пустой строки, соответствующей корню доменного дерева DNS. (Обычно в браузерах замыкающая точка отбрасывается, однако служба DNS-клиент (DNS Client) добавляет ее в запросах.)
Корень DNS (самый верхний уровень) доменного пространства Интернета управляется Корпорацией по присвоению имен и номеров в Интернете (Internet Corporation for Assigned Names and Numbers, ICANN). Корпорация ICANN координирует назначение идентификаторов, которые должны быть глобально уникальными, для работы в Интернете, включая доменные имена, значения IP-адресов, а также параметры протоколов и номера портов.
Помимо корня домена DNS корпорация ICANN также управляет доменами верхнего уровня. Существует три типа доменов верхнего уровня.
■ Организационные домены
Эти домены именуются с использованием кода, который указывает основную функцию или род деятельности организаций в DNS-домене. Некоторые такие домены могут использоваться глобально, другие применяются лишь для организаций в США. В качестве известных организационных доменов можно привести домены .com, .net, .edu и .org. Другие организационные домены верхнего уровня включают .aero, .biz, .info, .name и .pro.
■ Географические домены
Эти домены именуются с использованием кодов страны и региона из двух символов согласно стандарту 3166 Международной организации по стандартизации (International Organization for Standardization, ISO), например .uk (Великобритания) или .it (Италия). Эти домены обычно используются организациями вне США, хотя и необязательно.
■ Реверсивные домены
Специальные домены, именуемые in-addr.arpa, используемые для разрешения IP-адресов в имена (в реверсивном поиске).
Корень DNS (самый верхний уровень) доменного пространства Интернета управляется Корпорацией по присвоению имен и номеров в Интернете (Internet Corporation for Assigned Names and Numbers, ICANN). Корпорация ICANN координирует назначение идентификаторов, которые должны быть глобально уникальными, для работы в Интернете, включая доменные имена, значения IP-адресов, а также параметры протоколов и номера портов.
Помимо корня домена DNS корпорация ICANN также управляет доменами верхнего уровня. Существует три типа доменов верхнего уровня.
■ Организационные домены
Эти домены именуются с использованием кода, который указывает основную функцию или род деятельности организаций в DNS-домене. Некоторые такие домены могут использоваться глобально, другие применяются лишь для организаций в США. В качестве известных организационных доменов можно привести домены .com, .net, .edu и .org. Другие организационные домены верхнего уровня включают .aero, .biz, .info, .name и .pro.
■ Географические домены
Эти домены именуются с использованием кодов страны и региона из двух символов согласно стандарту 3166 Международной организации по стандартизации (International Organization for Standardization, ISO), например .uk (Великобритания) или .it (Италия). Эти домены обычно используются организациями вне США, хотя и необязательно.
■ Реверсивные домены
Специальные домены, именуемые in-addr.arpa, используемые для разрешения IP-адресов в имена (в реверсивном поиске).
Под доменами верхнего уровня корпорация ICANN и другие сообщества именования в Интернете (Network Solutions или Nominent в Великобритании) делегируют домены различным организациям, например Microsoft (microsoft.com) или университету (.edu). Эти организации подключаются к Интернету, назначают имена узлам в своих доменах и используют DNS-серверы для управления сопоставлением имен с IP-адресами в своем именном пространстве. Эти организации также могут делегировать субдомены другим пользователям или потребителям. Например, поставщики услуг Интернета (Internet Service Provider, ISP) принимают делегирование от ICANN и могут делегировать субдомены своим потребителям.
Частное доменное пространство имен Помимо доменов верхнего уровня в Интернете организации также могут иметь частное пространство имен — пространство имен DNS на основе набора приватных корневых серверов, которое не зависит от пространства имен DNS в Интернете. В приватном пространстве имен можно именовать и создавать собственные корневые серверы и любые субдомены. Приватные имена невозможно видеть или разрешать в Интернете. Примером имени приватного домена является имя mycompany.local.
Компоненты DNSДля работы DNS нужно обеспечить соответствующую конфигурацию DNS-серверов, зон, распознавателей и записей ресурсов.
DNS-серверы
DNS-серверы
DNS-сервер представляет собой компьютер с программой DNS-сервера (например, служба DNS-сервера в системе Windows Server или Berkeley Internet Name Domain (BIND) в UNIX). DNS-серверы содержат информацию базы данных DNS о некоторой части древовидной структуры доменов DNS и разрешают запросы разрешения имен, поступающие от DNS-клиентов. DNS-серверы могут обеспечивать запрашиваемую информацию, указатель на еще один сервер, который может помочь разрешить запрос, либо сообщают, что информация недоступна или не существует.
Сервер, использующий локально управляемую базу данных (вместо простого кэширования информации с других серверов), является главным сервером домена, отвечающим на запросы об узлах в этом домене. Такие серверы определяют свою часть именного пространства DNS.
Серверы могут быть главными на одном или нескольких уровнях иерархии доменов. В частности, корневые DNS-серверы в Интернете являются главными лишь для доменных имен верхнего уровня, например .com. В результате главные серверы доменов .com имеют приоритет лишь для имен в домене .com, например microsoft.com. Однако внутри пространства имен Microsoft главный сервер или серверы домена microsoft.com также могут быть главными в обоих доменах, например в доменах microsoft.com и widgets.example.microsoft.com.
Смежные домены, например .com, microsoft.com и example.microsoft.com, могут стать отдельными зонами в случае делегирования, посредством которого ответственность за субдомен в именном пространстве DNS назначается отдельной сущности.
Файлы зон содержат данные зон, для которых сервер является главным. Во многих типах реализации DNS-серверов данные зон хранятся в текстовых файлах, однако, DNS-серверы на контроллерах доменов Active Directory могут также хранить информацию зон в Active Directory.
ПРИМЕЧАНИЕ: Зоны прямого и обратного просмотра
Сервер, использующий локально управляемую базу данных (вместо простого кэширования информации с других серверов), является главным сервером домена, отвечающим на запросы об узлах в этом домене. Такие серверы определяют свою часть именного пространства DNS.
Серверы могут быть главными на одном или нескольких уровнях иерархии доменов. В частности, корневые DNS-серверы в Интернете являются главными лишь для доменных имен верхнего уровня, например .com. В результате главные серверы доменов .com имеют приоритет лишь для имен в домене .com, например microsoft.com. Однако внутри пространства имен Microsoft главный сервер или серверы домена microsoft.com также могут быть главными в обоих доменах, например в доменах microsoft.com и widgets.example.microsoft.com.
Смежные домены, например .com, microsoft.com и example.microsoft.com, могут стать отдельными зонами в случае делегирования, посредством которого ответственность за субдомен в именном пространстве DNS назначается отдельной сущности.
Файлы зон содержат данные зон, для которых сервер является главным. Во многих типах реализации DNS-серверов данные зон хранятся в текстовых файлах, однако, DNS-серверы на контроллерах доменов Active Directory могут также хранить информацию зон в Active Directory.
ПРИМЕЧАНИЕ: Зоны прямого и обратного просмотра
Зоны бывают двух типов: зоны прямого просмотра и зоны обратного просмотра. Основным типом является зона прямого просмотра, имена в которой разрешаются в IP-адреса. В зоне обратного просмотра IP-адрес разрешается в имя. Типы зон подробно описаны в главе 3.
Распознаватели DNSРаспознаватель DNS представляет службу, использующую протокол DNS для запроса информации DNS-серверов. Распознаватели DNS осуществляют коммуникации с удаленными DNS-серверами или программой DNS-сервера на локальном компьютере. В Windows Server 2008 роль распознавателя DNS выполняет служба DNS-клиент (DNS Client). Помимо функций распознавателя DNS служба DNS-клиент обеспечивает дополнительные возможности кэширования сопоставлений DNS.
Записи ресурсов
Записи ресурсов
Записи ресурсов представляют сущности базы данных DNS, которые используются для ответов на запросы клиентов DNS. Каждый DNS-сервер содержит записи ресурсов, которые использует для ответов на запросы своей части пространства имен DNS. Каждая запись ресурсов описана с конкретным типом ресурса, например адрес (А) IPv4-yзлa, адрес (АААА) IPv6-узла, псевдоним (CNAME), указатель (PTR) и почтовый обменщик MX (Mail eXchanger). Эти записи подробно описаны в теме 1 главы 3.
Запрос DNS
Когда DNS-клиенту требуется выполнить поиск имени, используемого приложением, он опрашивает DNS-серверы для разрешения этого имени. Каждое сообщение запроса, отправляемое клиентом, содержит следующие сведения.
■ Имя домена DNS, указанное в формате FQDN. (Служба DNS-клиент добавляет необходимые суффиксы для генерирования имени FQDN, если оно не было указано исходной клиентской программой.)
■ Указанный тип запроса, например запрос записи ресурса по типу или специализированный тип операции запроса.
■ Указанный класс доменного имени DNS. (Для службы DNS-клиент всегда указывается класс Internet [IN].
Так, в запросе можно указать имя FQDN конкретного компьютера (например, host-a.example.microsoft.com.), а в качестве типа запроса указать поиск записи А по этому имени. Запрос DNS как клиент задает серверу, скажем, такой вопрос: «Имеются ли записи А для компьютера hostname.example.microsoft.com?». Получив ответ от сервера, клиент читает полученную запись А и определяет IP-адрес имени компьютера, которое запрашивалось.
Методы разрешения имен DNS
■ Имя домена DNS, указанное в формате FQDN. (Служба DNS-клиент добавляет необходимые суффиксы для генерирования имени FQDN, если оно не было указано исходной клиентской программой.)
■ Указанный тип запроса, например запрос записи ресурса по типу или специализированный тип операции запроса.
■ Указанный класс доменного имени DNS. (Для службы DNS-клиент всегда указывается класс Internet [IN].
Так, в запросе можно указать имя FQDN конкретного компьютера (например, host-a.example.microsoft.com.), а в качестве типа запроса указать поиск записи А по этому имени. Запрос DNS как клиент задает серверу, скажем, такой вопрос: «Имеются ли записи А для компьютера hostname.example.microsoft.com?». Получив ответ от сервера, клиент читает полученную запись А и определяет IP-адрес имени компьютера, которое запрашивалось.
Методы разрешения имен DNS
Разрешение запросов DNS выполняется множеством различных способов. В базовом сценарии DNS-клиент связывается с DNS-сервером, который затем использует для ответа на запрос собственную базу данных записей ресурсов. Однако, ссылаясь вначале на свой кэш, DNS-клиент иногда может ответить на запрос, вообще не обращаясь к серверу. Еще один способ разрешения запросов DNS состоит в использовании рекурсии. При этом для разрешения имени FQDN DNS-сервер может запрашивать другие DNS-серверы от лица запрашивающего клиента. Получив ответ на запрос, DNS-сервер пересылает его клиенту. Последний метод разрешения запросов DNS состоит в применении итерации. В этом случае клиент сам пытается связаться с дополнительными DNS- серверами для разрешения имени. При этом клиент использует отдельные дополнительные запросы на основе ответов DNS-серверов. Как правило, клиент выполняет итерацию только в том случае, когда DNS-сервер не отконфигурирован для выполнения рекурсии.
Этапы выполнения запроса DNS
Этапы выполнения запроса DNS
Запрос DNS выполняется в два этапа.
■ С клиентского компьютера запускается запрос имени и передается службе
DNS-клиент (DNS Client) для разрешения.
■ Если запрос нельзя разрешить локально, служба DNS-клиент передает запрос DNS-серверу.
Далее подробно описаны оба этапа выполнения.
Этап 1. Локальный распознаватель
По умолчанию DNS-запрос клиента отконфигурирован для выполнения рекурсивных запросов сервера. Если в этом сценарии служба DNS-клиент не может разрешить запрос с помощью локально кэшированной информации (сопоставления имен с адресами, предварительно загружаемые из файла Hosts), клиент отправляет лишь один запрос на DNS-сервер, который затем выполняет его от лица клиента.
Процесс выполнения запроса начинается с использования доменного имени DNS в программе на локальном компьютере. Например, браузер запрашивает имя FQDN для www.microsoft.com. Затем запрос пересылается службе DNS-клиент (кэш распознавателя DNS) для разрешения этого имени с помощью локально кэшированной информации. Если такое имя можно разрешить, отправляется ответ на запрос, и процесс завершается.
Кэш локального распознавателя может включать информацию об имени, полученную из двух возможных источников.
■ При наличии локально отконфигурированного файла Hosts все сопоставления имен узлов в адреса загружаются из файла в кэш при запуске службы DNS- клиент и при каждом обновлении файла Hosts. В Windows Server 2008 записи динамически добавляются в кэш распознавателя, создавая файл Hosts.
■ Записи ресурсов, полученные в ответах на предыдущие запросы DNS, добавляются в кэш и хранятся там некоторое время.
Если запрос не соответствует ни одной записи в кэше, клиент запрашивает DNS-сервер для разрешения имени.
Этап 2. Запрос DNS-сервера
Служба DNS-клиент (DNS Client) использует список поиска серверов, упорядоченный согласно предпочтениям. В этот список включены все предпочтительные и альтернативные DNS-серверы, отконфигурированные для каждого активного сетевого подключения в системе. Клиент вначале запрашивает DNS-сервер, указанный как предпочтительный в диалоговом окне Свойства: Протокол Интернета (TCP/IP) (Internet Protocol (TCP/ IP) Properties). Если предпочтительные DNS-серверы недоступны, используются альтернативные DNS-серверы.
После получения запроса DNS-сервер проверяет возможность приоритетного ответа на запрос на основе информации, содержащейся в локально сконфигурированной зоне на сервере. Если запрашиваемое имя соответствует записи ресурса в данных локальной зоны, сервер отвечает на запрос в приоритетном порядке, используя эту информацию для разрешения запрашиваемого имени.
Если для запрашиваемого имени не нашлось соответствующей записи в информации зоны, сервер проверяет возможность разрешения имени с помощью локально кэшированной информации предыдущих запросов. Если найдена соответствующая запись, сервер отвечает на запрос. Если предпочтительный сервер находит ответ для запрашивающего клиента в своем кэше, выполнение запроса завершается.
Рекурсия
■ С клиентского компьютера запускается запрос имени и передается службе
DNS-клиент (DNS Client) для разрешения.
■ Если запрос нельзя разрешить локально, служба DNS-клиент передает запрос DNS-серверу.
Далее подробно описаны оба этапа выполнения.
Этап 1. Локальный распознаватель
По умолчанию DNS-запрос клиента отконфигурирован для выполнения рекурсивных запросов сервера. Если в этом сценарии служба DNS-клиент не может разрешить запрос с помощью локально кэшированной информации (сопоставления имен с адресами, предварительно загружаемые из файла Hosts), клиент отправляет лишь один запрос на DNS-сервер, который затем выполняет его от лица клиента.
Процесс выполнения запроса начинается с использования доменного имени DNS в программе на локальном компьютере. Например, браузер запрашивает имя FQDN для www.microsoft.com. Затем запрос пересылается службе DNS-клиент (кэш распознавателя DNS) для разрешения этого имени с помощью локально кэшированной информации. Если такое имя можно разрешить, отправляется ответ на запрос, и процесс завершается.
Кэш локального распознавателя может включать информацию об имени, полученную из двух возможных источников.
■ При наличии локально отконфигурированного файла Hosts все сопоставления имен узлов в адреса загружаются из файла в кэш при запуске службы DNS- клиент и при каждом обновлении файла Hosts. В Windows Server 2008 записи динамически добавляются в кэш распознавателя, создавая файл Hosts.
■ Записи ресурсов, полученные в ответах на предыдущие запросы DNS, добавляются в кэш и хранятся там некоторое время.
Если запрос не соответствует ни одной записи в кэше, клиент запрашивает DNS-сервер для разрешения имени.
Этап 2. Запрос DNS-сервера
Служба DNS-клиент (DNS Client) использует список поиска серверов, упорядоченный согласно предпочтениям. В этот список включены все предпочтительные и альтернативные DNS-серверы, отконфигурированные для каждого активного сетевого подключения в системе. Клиент вначале запрашивает DNS-сервер, указанный как предпочтительный в диалоговом окне Свойства: Протокол Интернета (TCP/IP) (Internet Protocol (TCP/ IP) Properties). Если предпочтительные DNS-серверы недоступны, используются альтернативные DNS-серверы.
После получения запроса DNS-сервер проверяет возможность приоритетного ответа на запрос на основе информации, содержащейся в локально сконфигурированной зоне на сервере. Если запрашиваемое имя соответствует записи ресурса в данных локальной зоны, сервер отвечает на запрос в приоритетном порядке, используя эту информацию для разрешения запрашиваемого имени.
Если для запрашиваемого имени не нашлось соответствующей записи в информации зоны, сервер проверяет возможность разрешения имени с помощью локально кэшированной информации предыдущих запросов. Если найдена соответствующая запись, сервер отвечает на запрос. Если предпочтительный сервер находит ответ для запрашивающего клиента в своем кэше, выполнение запроса завершается.
Рекурсия
Если запрашиваемое имя не найдено на предпочтительном сервере, в его кэше или данных зоны, дальнейший процесс выполнения запроса зависит от конфигурации DNS-серверов. В конфигурации по умолчанию DNS-сервер выполняет рекурсию для разрешения имени. В терминологии DNS рекурсия представляет собой процесс опроса DNS-сервером других DNS-серверов от лица исходного запрашивающего клиента. В этом процессе исходный DNS-сервер выполняет роль DNS-клиента.
Если рекурсия отключена на DNS-сервере, клиент сам выполняет итеративные запросы в соответствии с корневыми ссылками на DNS-сервере. Итерация представляет собой процесс выполнения DNS-клиентом многократных запросов различных DNS-серверов.
Корневые ссылкиДля правильного выполнения рекурсии DNS-серверу вначале требуется определить точку начала поиска имен в доменном пространстве DNS. Эта информация обеспечивается в виде корневых ссылок - предварительного списка ресурсов, используемого службой DNS с целью локализации главных серверов корня дерева пространства доменных имен DNS.
По умолчанию DNS-серверы в Windows Server 2008 используют предварительно отконфигурированный файл корневых ссылок Cache.dns из папки WINDOWS\System32\Dns. Содержимое этого файла загружается в память сервера при запуске службы и включает указатели на корневые серверы пространства имен DNS.
В Windows Server 2008 файл корневых ссылок уже содержит адреса корневых серверов в пространстве имен DNS Интернета. Поэтому в случае использования службы DNS-сервер в Windows Server 2008 для разрешения DNS-имени Интернета, файл корневых ссылок нужно конфигурировать вручную. В случае использования службы DNS в локальной сети этот файл можно отредактировать или заменить аналогичными записями, указывающими внутренние корневые DNS-серверы. Более того, на компьютере, который управляет корневым DNS-серве- ром, вообще не нужно использовать корневые ссылки. В этом сценарии Windows Server 2008 автоматически удаляет файл корневых ссылок Cache.dns.
Пример запроса
В следующем примере продемонстрирован запрос DNS. Клиент запрашивает предпочтительный DNS-сервер, который затем выполняет рекурсию, запрашивая DNS-серверы, расположенные выше в иерархии. Предполагается, что кэши DNS-клиента и всех DNS-серверов пусты.
Ниже описан процесс обработки запроса службой DNS-клиент на клиентском компьютере.
1. Клиент связывается с сервером NameServer1 и запрашивает example.wikipedia.org.
2. Сервер NameServer1 проверяет свой кэш и зоны. Если ответ не получен, он обращается к главному серверу Интернета (т. е. корневому серверу) и запрашивает example.wikipedia.org.
3. Корневой сервер Интернета не знает ответ и запрашивает направление на главный сервер домена .org.
4. Сервер NameServer1 обращается к главному серверу домена .org и запрашивает имя example.wikipedia.org.
5. Главный сервер домена .org не знает точный ответ и направляет запрос на главный сервер домена wikipedia.org.
6. Сервер NameServer1 обращается к главному серверу домена wikipedia.org и запрашивает имя example.wikipedia.org.
7. Главный сервер домена wikipedia.org знает ответ и отправляет запрашиваемый IP-адрес.
8. Сервер NameServer1 отправляет в ответе на запрос клиента IP-адрес узла
example.wikipedia.org..
Кэширование
Ниже описан процесс обработки запроса службой DNS-клиент на клиентском компьютере.
1. Клиент связывается с сервером NameServer1 и запрашивает example.wikipedia.org.
2. Сервер NameServer1 проверяет свой кэш и зоны. Если ответ не получен, он обращается к главному серверу Интернета (т. е. корневому серверу) и запрашивает example.wikipedia.org.
3. Корневой сервер Интернета не знает ответ и запрашивает направление на главный сервер домена .org.
4. Сервер NameServer1 обращается к главному серверу домена .org и запрашивает имя example.wikipedia.org.
5. Главный сервер домена .org не знает точный ответ и направляет запрос на главный сервер домена wikipedia.org.
6. Сервер NameServer1 обращается к главному серверу домена wikipedia.org и запрашивает имя example.wikipedia.org.
7. Главный сервер домена wikipedia.org знает ответ и отправляет запрашиваемый IP-адрес.
8. Сервер NameServer1 отправляет в ответе на запрос клиента IP-адрес узла
example.wikipedia.org..
Кэширование
Кэширование поддерживают обе службы — DNS-клиент и DNS-сервер. Кэширование повышает производительность DNS и значительно снижает уровень трафика запросов DNS в сети.
Кэш DNS-клиента
Кэш DNS-клиента еще называют кэшем распознавателя DNS. При каждом запуске службы DNS-клиент все сопоставления имен в IP-адреса, содержащиеся в статическом файле Hosts, предварительно загружаются в кэш распознавателя DNS. Файл Hosts находится в папке WINDOWS\System32\Drivers\Etc.
ПРИМЕЧАНИЕ: Использование файла Hosts
Каждая запись, добавляемая в файл Hosts, немедленно загружается в кэш распознавателя DNS.
Помимо записей в файле Hosts кэш распознавателя DNS также включает записи, получаемые клиентом в ответ на запросы DNS-серверов. Каждый раз при остановке службы DNS-клиент (DNS Client) выполняется очистка кэша распознавателя DNS.
Кэш DNS-сервера
Поскольку DNS-серверы выполняют рекурсивные запросы от лица клиентов, они временно кэшируют записи ресурсов. Эти кэшированные записи содержат информацию, получаемую в ответах на запросы от лица клиента. Позже, при получении новых запросов информации, соответствующей кэшированным записям ресурсов, DNS-сервер может использовать кэшированную информацию для ответа на эти запросы.
Очистка кэша DNS-сервера выполняется каждый раз при остановке службы DNS-сервера. Очистку кэша DNS-сервера можно выполнить и вручную в консоли DNS (инструмент, используемый для администрирования DNS), щелкнув правой кнопкой мыши значок сервера в дереве консоли и применив команду Очистить кэш (Clear Cache). Наконец, кэш сервера можно очистить, запустив в командной строке команду Dnscmd/clearcache.
Значения Time To Live (TTL)
Время жизни датаграммы в секундах применяется ко всем кэшированным записям ресурсов в кэше распознавателя DNS и кэше DNS-сервера. Во время жизни TTL кэшированного ресурса распознаватель или сервер DNS может использовать эту запись для ответа на запросы. По умолчанию назначается значение TTL 3600 с (1 ч), однако этот параметр можно изменять на уровнях зоны и записи.
Очистка кэша DNS-сервера выполняется каждый раз при остановке службы DNS-сервера. Очистку кэша DNS-сервера можно выполнить и вручную в консоли DNS (инструмент, используемый для администрирования DNS), щелкнув правой кнопкой мыши значок сервера в дереве консоли и применив команду Очистить кэш (Clear Cache). Наконец, кэш сервера можно очистить, запустив в командной строке команду Dnscmd/clearcache.
Значения Time To Live (TTL)
Время жизни датаграммы в секундах применяется ко всем кэшированным записям ресурсов в кэше распознавателя DNS и кэше DNS-сервера. Во время жизни TTL кэшированного ресурса распознаватель или сервер DNS может использовать эту запись для ответа на запросы. По умолчанию назначается значение TTL 3600 с (1 ч), однако этот параметр можно изменять на уровнях зоны и записи.
Читайте следующую тему: "Установка DNS-сервера"
Комментариев нет:
Отправить комментарий