Какой протокол обеспечивает именование и разрешение имен в рабочих группах windows
Обновлено: 07.07.2024
Конфигурирование стека TCP/IP в среде Windows NT связано с назначением IP-адреса и имени компьютера, которые уникально идентифицируют каждый компьютер в сети. Для сети TCP/IP и сети Internet используется составное имя компьютера - это глобально известное системное имя плюс имя домена DNS. (В локальной сети Microsoft имя компьютера - это имя в стиле протокола NetBIOS, которое было определено во время инсталляции Windows NT.)
Для идентификации друг друга компьютеры используют IP-адреса, но пользователи обычно предпочитают работать с именами компьютеров. Следовательно, в сети TCP/IP должен быть предусмотрен механизм для установления соответствия между именами и IP-адресами. Для того, чтобы обеспечить уникальность как имени, так и адреса, компьютер Windows NT, использующий TCP/IP, регистрирует свое имя и IP-адрес во время старта системы. Компьютер Windows NT может использовать один или несколько из следующих методов для того, чтобы обеспечить корректное разрешение имен в интерсетях TCP/IP.
-
Windows Internet Name Service (WINS)
Компьютеры Windows NT могут использовать сервис WINS, если в сети имеется один или несколько серверов WINS, которые содержат динамическую базу данных, отображающую имена компьютеров на IP-адреса. WINS может использоваться в сочетании с широковещательным разрешением имен для интерсети, в которой другие методы разрешения имен не работают. Как описывается в следующем разделе, WINS - режим работы NetBIOS поверх TCP/IP, определенный в RFC 1001/1002 как режим p-node.
В Windows NT 4.0 реализован клиент службы DNS (Domain Name System). Служба DNS обеспечивает способ просмотра отображения имен при подключения компьютеров к посторонним (не Windows NT) хостам, в которых работают DNS-серверы. Эта служба предназначена для тех случаев, когда подключение осуществляется путем использования NetBIOS поверх TCP/IP или для приложений, использующих интерфейс Windows Sockets, таких как FTP. DNS - это распределенная база данных, разработанная для решения задач направления трафика, которые возникли во время быстрого роста сети Internet в начале 80-х годов.
Файл HOSTS используется приложениями, работающим с интерфейсом Windows Sockets, а файл LMHOSTS используется приложениями, работающими с интерфейсом NetBIOS поверх TCP/IP. Файл LMHOSTS используется обычно для разрешения имен в сетях небольшого масштаба, где служба WINS не установлена.
Преимущества и недостатки NetBIOS
Главное ограничение NetBIOS состоит в том, что, хотя этот протокол обеспечивает резервный метод разрешения имен компьютеров в пределах диапазона широковещания и небольших сетях, он неэффективен в больших сетях. В NetBIOS каждому компьютеру назначается только одно имя или метка. Если вы используете WINS для разрешения имен NetBIOS в подсетях, имя каждого компьютера должно быть уникальным для всей сети. Еще один недостаток NetBIOS состоит в том, что этот протокол не рекомендуется использовать в тех случаях, когда требуется высокий уровень безопасности. Система NetBIOS разглашает информацию о сетевых службах, которая может быть использована для взлома сети. И, наконец, протокол NetBIOS несовместим с IPv 6-сетями.
ПРИМЕЧАНИЕ:
Если вы используете множество WINS-серверов в большой организации, па них нужно отконфигурировать репликацию, чтобы базы данных WINS все время обновлялись. В большинстве случаев на всех WINS-серверах настраивается репликация приема/передачи (push/pull) (особенно при звездообразной конфигурации), чтобы серверы могли эффективно обновлять друг друга.
Разрешение имен DNS
Система DNS позволяет определять по имени компьютеры и другие ресурсы в Интернете. Обеспечивая иерархическую структуру и автоматизированный метод кэширования и разрешения имен узлов, DNS устраняет многие административные и организационные вопросы, связанные с именованием узлов в Интернете и больших частных сетях.Система именования DNS основана на иерархической и логической древовидной структуре, которая называется пространством имен DNS. Это пространство имеет уникальный корень с любым количеством субдоменов. Каждый субдомен может располагать доменами нижнего уровня. Например, корень "" (пустая строка) в пространстве имен Интернета располагает множеством доменных имен верхнего уровня, одним из которых является org . Домен org может, например, содержать субдомен wikipedia . org компании Wikipedia , который, в свою очередь, может располагать производственным субдоменом ru . wikipedia . org . Организации также могут создавать частные сети и использовать собственное пространство имен DNS, скрытое для Интернета.
Доменные имена
Для работы DNS нужно обеспечить соответствующую конфигурацию DNS-серверов, зон, распознавателей и записей ресурсов.
Зоны бывают двух типов: зоны прямого просмотра и зоны обратного просмотра. Основным типом является зона прямого просмотра, имена в которой разрешаются в IP-адреса. В зоне обратного просмотра IP-адрес разрешается в имя. Типы зон подробно описаны в главе 3.Распознаватель DNS представляет службу, использующую протокол DNS для запроса информации DNS-серверов. Распознаватели DNS осуществляют коммуникации с удаленными DNS-серверами или программой DNS-сервера на локальном компьютере. В Windows Server 2008 роль распознавателя DNS выполняет служба DNS-клиент (DNS Client). Помимо функций распознавателя DNS служба DNS-клиент обеспечивает дополнительные возможности кэширования сопоставлений DNS.
Записи ресурсов
Методы разрешения имен 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-серверы в 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-клиента
Кэш 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).
Платформа одноранговых сетей Microsoft® Windows® решает эту проблему за счет применения протокола PNRP, который представляет собой безопасный масштабируемый динамический протокол регистрации и разрешения имен, изначально разработанный для Windows XP и позднее модернизированный для Windows Vista™. Принципы работы протокола PNRP значительно отличаются от других традиционных систем разрешения имен, что открывает перед разработчиками совершенно новые возможности.
При использовании протокола PNRP имена одноранговых узлов могут назначаться компьютерам, отдельным приложениям или службам на компьютере. Процесс разрешения имен одноранговых узлов включает адрес, порт и, возможно, расширенные полезные данные. К преимуществам такой системы относятся высокая отказоустойчивость, отсутствие узких мест и механизм разрешения имен, ни при каких обстоятельствах не возвращающий устаревшие адреса, что делает этот протокол оптимальным решением для обнаружения мобильных пользователей.
С точки зрения безопасности имена одноранговых узлов могут публиковаться в безопасной (защищенной) или небезопасной (незащищенной) форме. Протокол PNRP использует шифрование с открытым ключом для защиты безопасных имен одноранговых узлов от подделки. Протокол PNRP можно использовать для присвоения имен как компьютерам, так и службам.
Протокол PNRP характеризуется следующими свойствами:
Распределенность и практически полное отсутствие серверов. Использование серверов только в процессе начальной загрузки.
Публикация безопасных имен без привлечения третьих лиц. В отличие от службы DNS, публикация имен с использованием протокола PNRP осуществляется мгновенно и не требует финансовых затрат.
Обновления протокола PNRP осуществляются в режиме реального времени, что позволяет исключить разрешение устаревших адресов.
Протокол PNRP поддерживает разрешение имен не только для компьютеров, но и для служб.
(Распознаватели PNRP и пользовательские одноранговые распознаватели, а также их экземпляры могут создаваться с использованием типов, представленных в пространстве имен System.ServiceModel.PeerResolvers.)
Ниже приведены базовые типы, используемые для регистрации и разрешения имен с использованием доступной службы PNRP:
Cloud. Определяет сведения, описывающие доступное облако PNRP, включая его область действия.
PeerName. Определяет имя однорангового узла, которое может использоваться для регистрации и последующего разрешения этого узла в облаке.
PeerNameRecord. Определяет запись в облаке PNRP, которая содержит сведения о регистрации для однорангового узла, включая сетевые конечные точки доступа, которые могут использоваться для связи с этим узлом.
PeerNameRegistration. Определяет процесс регистрации имени однорангового узла, включая методы запуска и остановки регистрации.
PeerNameResolver. Определяет процесс разрешения имени однорангового узла в его сетевые конечные точки, включая синхронные и асинхронные методы разрешения.
В очередном «конспекте админа» остановимся на еще одной фундаментальной вещи – механизме разрешения имен в IP-сетях. Кстати, знаете почему в доменной сети nslookup на все запросы может отвечать одним адресом? И это при том, что сайты исправно открываются. Если задумались – добро пожаловать под кат. .
Для преобразования имени в IP-адрес в операционных системах Windows традиционно используются две технологии – NetBIOS и более известная DNS.
NetBIOS (Network Basic Input/Output System) – технология, пришедшая к нам в 1983 году. Она обеспечивает такие возможности как:
регистрация и проверка сетевых имен;
установление и разрыв соединений;
связь с гарантированной доставкой информации;
связь с негарантированной доставкой информации;
В рамках этого материала нас интересует только первый пункт. При использовании NetBIOS имя ограниченно 16 байтами – 15 символов и спец-символ, обозначающий тип узла. Процедура преобразования имени в адрес реализована широковещательными запросами.
Небольшая памятка о сути широковещательных запросов.Широковещательным называют такой запрос, который предназначен для получения всеми компьютерами сети. Для этого запрос посылается на специальный IP или MAC-адрес для работы на третьем или втором уровне модели OSI.
Для работы на втором уровне используется MAC-адрес FF:FF:FF:FF:FF:FF, для третьего уровня в IP-сетях адрес, являющимся последним адресом в подсети. Например, в подсети 192.168.0.0/24 этим адресом будет 192.168.0.255
Естественно, постоянно рассылать широковещательные запросы не эффективно, поэтому существует кэш NetBIOS – временная таблица соответствий имен и IP-адреса. Таблица находится в оперативной памяти, по умолчанию количество записей ограничено шестнадцатью, а срок жизни каждой – десять минут. Посмотреть его содержимое можно с помощью команды nbtstat -c, а очистить – nbtstat -R.
Пример работы кэша для разрешения имени узла «хр».
Что происходило при этом с точки зрения сниффера.
В крупных сетях из-за ограничения на количество записей и срока их жизни кэш уже не спасает. Да и большое количество широковещательных запросов запросто может замедлить быстродействие сети. Для того чтобы этого избежать, используется сервер WINS (Windows Internet Name Service). Адрес сервера администратор может прописать сам либо его назначит DHCP сервер. Компьютеры при включении регистрируют NetBIOS имена на сервере, к нему же обращаются и для разрешения имен.
В сетях с *nix серверами можно использовать пакет программ Samba в качестве замены WINS. Для этого достаточно добавить в конфигурационный файл строку «wins support = yes». Подробнее – в документации.
В отсутствие службы WINS можно использовать файл lmhosts, в который система будет «заглядывать» при невозможности разрешить имя другими способами. В современных системах по умолчанию он отсутствует. Есть только файл-пример-документация по адресу %systemroot%\System32\drivers\etc\lmhost.sam. Если lmhosts понадобится, его можно создать рядом с lmhosts.sam.
Сейчас технология NetBIOS не на слуху, но по умолчанию она включена. Стоит иметь это ввиду при диагностике проблем.
если в кэше резолвера адреса нет, система запрашивает указанный в сетевых настройках интерфейса сервер DNS;
Наглядная схема прохождения запроса DNS.
Разумеется, DNS не ограничивается просто соответствием «имя – адрес»: здесь поддерживаются разные виды записей, описанные стандартами RFC. Оставлю их список соответствующим статьям.
Сам сервис DNS работает на UDP порту 53, в редких случаях используя TCP.
DNS переключается на TCP с тем же 53 портом для переноса DNS-зоны и для запросов размером более 512 байт. Последнее встречается довольно редко, но на собеседованиях потенциальные работодатели любят задавать вопрос про порт DNS с хитрым прищуром.
Также как и у NetBIOS, у DNS существует кэш, чтобы не обращаться к серверу при каждом запросе, и файл, где можно вручную сопоставить адрес и имя – известный многим %Systemroot%\System32\drivers\etc\hosts.
В отличие от кэша NetBIOS в кэш DNS сразу считывается содержимое файла hosts. Помимо этого, интересное отличие заключается в том, что в кэше DNS хранятся не только соответствия доменов и адресов, но и неудачные попытки разрешения имен. Посмотреть содержимое кэша можно в командной строке с помощью команды ipconfig /displaydns, а очистить – ipconfig /flushdns. За работу кэша отвечает служба dnscache.
На скриншоте видно, что сразу после чистки кэша в него добавляется содержимое файла hosts, и иллюстрировано наличие в кэше неудачных попыток распознавания имени.
При попытке разрешения имени обычно используются сервера DNS, настроенные на сетевом адаптере. Но в ряде случаев, например, при подключении к корпоративному VPN, нужно отправлять запросы разрешения определенных имен на другие DNS. Для этого в системах Windows, начиная с 7\2008 R2, появилась таблица политик разрешения имен (Name Resolution Policy Table, NRPT). Настраивается она через реестр, в разделе HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DnsClient\DnsPolicyConfig или групповыми политиками.
Настройка политики разрешения имен через GPO.
При наличии в одной сети нескольких технологий, где еще и каждая – со своим кэшем, важен порядок их использования.
Операционная система Windows пытается разрешить имена в следующем порядке:
проверяет, не совпадает ли имя с локальным именем хоста;
смотрит в кэш DNS распознавателя;
если в кэше соответствие не найдено, идет запрос к серверу DNS;
если не получилось разрешить имя на этом этапе – происходит запрос на сервер WINS;
если постигла неудача, то система пытается получить имя широковещательным запросом, но не более трех попыток;
Для удобства проиллюстрирую алгоритм блок-схемой:
Алгоритм разрешения имен в Windows.
Выполнение второго пинга происходит на несколько секунд дольше, а сниффер покажет широковещательные запросы.
Сниффер показывает запросы DNS для длинного имени и широковещательные запросы NetBIOS для короткого.
Отдельного упоминания заслуживают доменные сети – в них запрос с коротким именем отработает чуть по-другому.
Для того чтоб при работе не нужно было вводить FQDN, система автоматически добавляет часть имени домена к хосту при различных операциях – будь то регистрация в DNS или получение IP адреса по имени. Сначала добавляется имя домена целиком, потом следующая часть до точки.
При попытке запуска команды ping servername система проделает следующее:
Настройка добавления суффиксов DNS через групповые политики.
Настраивать DNS суффиксы можно также групповыми политиками или на вкладке DNS дополнительных свойств TCP\IP сетевого адаптера. Просмотреть текущие настройки удобно командой ipconfig /all.
Суффиксы DNS и их порядок в выводе ipconfig /all.
Из-за суффиксов утилита nslookup выдала совсем не тот результат, который выдаст например пинг:
Это поведение иногда приводит в замешательство начинающих системных администраторов.
При диагностике стоит помнить, что утилита nslookup работает напрямую с сервером DNS, в отличие от обычного распознавателя имен. Если вывести компьютер из домена и расположить его в другой подсети, nslookup будет показывать, что всё в порядке, но без настройки суффиксов DNS система не сможет обращаться к серверам по коротким именам.
Отсюда частые вопросы – почему ping не работает, а nslookup работает.
В плане поиска и устранения ошибок разрешения имен могу порекомендовать не бояться использовать инструмент для анализа трафика – сниффер. С ним весь трафик как на ладони, и если добавляются лишние суффиксы, то это отразится в запросах DNS. Если запросов DNS и NetBIOS нет, некорректный ответ берется из кэша.
Если же нет возможности запустить сниффер, рекомендую сравнить вывод ping и nslookup, очистить кэши, проверить работу с другим сервером DNS.
Кстати, если вспомните любопытные DNS-курьезы из собственной практики – поделитесь в комментариях.
Когда речь идет о сетевом обмене информацией, протоколы TCP/IP полностью основываются на IP-адресах для идентификации других компьютеров. Кроме того, для идентификации сетевых компьютеров используются хост-имена и имена NetBIOS, чтобы компьютерам было проще устанавливать контакт друг с другом. Но невозможно запомнить IP-адрес каждого компьютера или каждого веб-сайта, с которыми вы хотите устанавливать контакт.
В операционных системах Microsoft до Windows 2000 сетевой обмен всегда основывался на именах NetBIOS. Система Windows Server 2003 продолжает поддерживать имена NetBIOS для совместимости, но она разработана для использования в первую очередь хост-имен, а не имен NetBIOS. В любом случае требуется метод, позволяющий устанавливать соответствие между этими именами и IP-адресами.
Для выполнения этих задач вы можете использовать различные методы с различными уровнями сложности, но все они могут быть сведены к базе данных, содержащей эти имена и эквивалентные IP-адреса. Отличия в этих механизмах определяются методами, которые используются для внесения информации в эту базу данных ( регистрация имен) и способами считывания информации (разрешение имен).
Если у вас действует сеть Windows Server 2003 с клиентами более ранних версий Windows (до Windows 2000), то вам нужно иметь как минимум два различных механизма разрешения имен. Хост-имена и имена NetBIOS всегда обрабатываются отдельно в этом отношении, даже если на компьютере эти имена совпадают. Если в вашей сети нет клиентов более ранних версий Windows или приложений на основе NetBIOS, то вы можете не поддерживать имена NetBIOS.
Все Windows -компьютеры применяют по крайней мере один из этих механизмов во время любого обмена данных TCP/IP , где используются имена, а не IP-адреса. Понимание того, как они действуют, поможет вам максимально повысить эффективность вашей сети, свести к минимуму сетевой трафик и справляться с проблемами передачи данных. Для более полного ознакомления с такими понятиями, как хост-имена, доменная иерархия , DNS и т.д. обратитесь к "Ознакомление с DNS" .
Использование файла HOSTS
Самый простой способ разрешения хост-имен – это ведение таблицы этих имен и соответствующих им IP-адресов. Этой задаче отвечает файл HOSTS – ASCII-файл, который хранится на локальном жестком диске и в котором слева содержатся IP-адреса и справа хост-имена. Если пользователь передает в какое-либо приложение хост-имя, это приложение ищет его в файле HOSTS. Если это имя найдено, то эквивалентный ему IP-адрес используется для создания сетевого соединения. Если имя не найдено, то соединение не может быть установлено.
Хотя в это трудно поверить, но в свое время услуги разрешения имен для всего интернета предоставлялись с помощью одной таблицы HOSTS, содержащей тысячи записей, которые должны были регулярно скачиваться пользователями интернета для обновления их файла. Проблемы использования этого метода очевидны. Вставку имен и адресов в файл для их регистрации можно выполнять только вручную. Пользователи или администраторы должны по отдельности изменять или обновлять файл HOSTS на каждом сетевом компьютере, чтобы включить имя и адрес каждого хоста, к которому нужно обращаться по имени. Кроме того, число записей растет, файл быстро увеличивается в размерах, что начинает влиять на скорость разрешения имен. Вообразите, что вам приходится управлять файлом HOSTS с сотнями или тысячами записей для отображения имен в IP-адреса. Каждое изменение этого файла потребовало бы обновления на всех компьютерах сети, то есть пересылки файла HOSTS каждому из них.
Использование системы доменных имен (DNS)
Система доменных имен (DNS – Domain Name System) – это наиболее распространенный метод разрешения хост-имен интернет, поскольку он позволяет пользователям подсоединяться к любому сайту в Internet по имени. Это может показаться невероятно трудным, особенно в свете роста интернета за последние несколько лет, но DNS использует доменную структуру хост-имен интернет и, конечно, является основной причиной ее использования.
Система доменных имен состоит из тысяч серверов DNS, распределенных по всей сети интернет. Если вы регистрируете какое-либо доменное имя, то должны обязательно указать основной (primary) и резервный (backup) сервер DNS. Их называют доверяемыми (authoritative) серверами для вашего домена. Сервер DNS – это демон UNIX или служба Windows, отвечающая за поддержку и публикацию базы данных хост-имен и адресов в ее собственном домене.
Серверы DNS какого-либо домена не обязательно должны находиться в его собственной сети, и действительно, многие провайдеры услуг интернета (ISP) поддерживают службы веб-хостинга, в которых они предоставляют использование их серверов DNS за плату. Здесь важно то, что уполномоченный орган интернет или другая организация, зарегистрировавшая имя этого домена, имеет запись для серверов DNS, ответственных за хосты этого домена.
Поскольку администраторы отдельных сетей отвечают за назначение хост-имен в своих доменах, они также должны обеспечивать поддержку записей DNS для этих имен. Удивительно, но регистрация хост-имен домена на его серверах DNS – это такая же ручная операция, как и для файла HOSTS. Например, если вы добавляете новый сервер ftp к своей сети, то должны вручную добавить или изменить ресурсную запись DNS, указав имя и адрес новой машины.
Однако в Windows Server 2003 была принята новая технология – динамическая регистрация компьютеров вместо утомительного ручного обновления ресурсных записей. Клиенты могут сделать так, чтобы их ресурсные A-записи (адресные записи для хостов) и PTR-записи (указатели для обратного поиска) регистрировались автоматически сервером DNS. Кроме того, DNS Windows Server 2003 может быть интегрирована с Active Directory (AD), что повышает уровень безопасности, улучшает репликацию базы данных DNS, администрирование и многое другое. DNS и связанные с ней темы подробно описываются в "Ознакомление с DNS" .
Имена NetBIOS
Хотя NetBIOS больше не является обязательным компонентом в сети Windows Server 2003, она важна для обратной совместимости с предыдущими системами Windows, такими как Windows 9x и Windows NT, где для обмена данных используется NetBIOS, а также с приложениями, которые используют NetBIOS.
NetBIOS – это программный интерфейс, который использовался на протяжении многих лет для предоставления возможностей сетевого обмена приложениям. Некоторые возможности исходной архитектуры Windows NT, встроенные в Windows Server 2003, полностью основывались на системе именования NetBIOS для именования других компьютеров в сети.
Имя NetBIOS содержит до 16 символов, последний из которых регистрируется в Windows для идентификации конкретных функций определенных компьютеров, например, контроллеров домена или браузеров. Если включена служба NetBIOS, то каждому компьютеру операционной системой присваивается имя NetBIOS. Это имя может совпадать или не совпадать с именем входа пользователя или хост-именем компьютера. Вы используете имена NetBIOS, когда вводите UNC-имя пути, указывающее какой-либо узел сети Windows.
NetBIOS уже не является обязательным компонентом, если у вас нет клиентов более ранних версий Windows или зависящих от NetBIOS приложений, но это все еще составная часть сетевых средств Windows. Службы Workstation и Server, которые запускаются на всех компьютерах Windows Server 2003/2000, используют как NetBIOS, так и непосредственный хостинг (direct hosting) для предоставления базовых услуг разделяемого доступа к файлам, которые запрашиваются какой-либо операционной системой. Непосредственный хостинг – это протокол, который использует для разрешения имен DNS, а не NetBIOS. По умолчанию задана конфигурация, в которой включены как NetBIOS, так и непосредственный хостинг, которые используются одновременно при разрешении имен для новых соединений с другими машинами.
Поскольку NetBIOS запускается поверх интерфейса Transport Device Interface ( TDI ), она может теоретически использовать любые совместимые протоколы для своих нужд низкоуровневого взаимодействия. Первоначально операционные системы, предшествовавшие Windows 2000, использовали для трафика NetBIOS интерфейс NetBEUI (NetBIOS Extended Use Interface). Однако NetBEUI не является маршрутизируемым, поэтому, когда в качестве альтернативы был предложен TCP/IP, была начата разработка открытого стандарта (опубликованного в дальнейшем в виде документа RFC), чтобы определить способ, посредством которого можно было бы предоставлять услуги NetBIOS, используя протоколы TCP/IP. Этот стандарт получил название NetBIOS over TCP/IP, или NetBT.
В запросах к сетевым службам, которые генерируются интерфейсом NetBIOS, для обращения к другим системам используются NetBIOS-имена компьютеров. Чтобы TCP/IP мог передавать запросы через сеть, имена NetBIOS (аналогично хост-именам) должны быть сначала разрешены (преобразованы) в IP-адреса.
Поскольку имена NetBIOS преобразуются в IP-адреса до передачи данных, то вы можете использовать их вместо хост-имен во внутренних сетях. Например, чтобы подсоединиться к веб-серверу интранет, пользователь может задать NetBIOS-имя этого сервера вместо обычного хост-имени. Аналогичным образом, вы можете использовать хост-имя в UNC-пути вместо NetBIOS-имени.
Типы узлов
В стандарте NetBT определены несколько типов узлов, которые указывают, какие методы и в каком порядке должен использовать компьютер. Типы узлов присваиваются клиентам сервером DHCP или определяются параметрами TCP/IP, заданными в конфигурации клиента. В стандарте NetBT определяются следующие типы узлов.
Когда сервер WINS успешно регистрирует определенное имя NetBIOS, он назначает дату истечения срока регистрации в форме значения TTL (time-to-live). Каждый раз, когда компьютер выполняет вход в сеть, это значение обновляется. Пока не истечет этот период времени, любая попытка зарегистрировать данное NetBIOS-имя будет отклоняться. Но если за этот период времени не будет выполнено ни одного входа, то данное NetBIOS-имя будет освобождено и может быть назначено снова сервером WINS без запроса какого-либо компьютера. Если данное имя остается неиспользованным в течение указанного периода времени, то объявляется как вышедшее из употребления и стирается из базы данных WINS.
Читайте также: