Разрешение имен узлов в сетях Microsoft
В ОС Windows NT для разрешения имен узлов можно использовать не только файл HOSTS и сервер DNS, но и сервер имен NetBIOS, широковещание и файл LMHOSTS . Если один из этих методов не сработает, то другие его подстрахуют.
Последовательность действий при разрешении имени с использованием NBNS и LMHOSTS 1-MHOSTS описана ниже:
1. Когда пользователь вводит команду и указывает имя узла, Windows NT сравнивает его с именем локального узла. Если они совпадают, то имя разрешается и команда выполняется (сеть при этом не задействована).
2. Если введенное имя узла и имя локального узла не совпадают, то просматривается файл HOSTS. В случае обнаружения в нем указанного имени оно разрешается IP-адрес, и начинается разрешение самого адреса. Файл HOSTS должен находиться в локальной системе.
3. Если имя узла не удалось разрешить при помощи файла HOSTS, то узел-отправитель посылает запрос к указанным в его конфигурации серверам DNS. Обнаруженное сервером DNS, имя узла разрешается в IP-адрес, и начинается процесс разрешения адреса.
Если сервер DNS не отвечает на запрос, то с интервалом в 5, 10, 20, 40, 5 10 и 20 секунд посылаются повторные запросы.
4. Если сервер DNS не может разрешить имя узла, то перед попыткой связаться со своими серверами имен NetBIOS узел-отправитель просматривает локальный кэш имен NetBIOS. Если имя узла обнаружено в нем или зарегистрировано на сервере имен NetBIOS, то оно успешно разрешается в IP-адрес и начинается процесс разрешения адреса.
5. Если имя узла не было разрешено сервером имен NetBIOS, то исходный узел посылает три широковещательных сообщения в локальную сеть. Обнаруженное в локальной сети, такое имя разрешается в IP-адрес и начинается процесс разрешения адреса.
6. Если не удалось разрешить имя при помощи широковещания, то привлекается локальный файл LMHOSTS. Обнаруженное в этом файле имя узла разрешается в IP-адрес и начинается разрешение адреса. Если ни один из этих методов не позволил разрешить имя узла, то единственный способ связи с этим узлом - явно указать его IP-адрес.
Файл HOSTS
Файл HOSTS - это статический файл, используемый для хранения соответствий имен узлов и IP-адресов. Он совместим с файлом HOSTS из ОС UN1X. Файл HOSTS применяется программой Ping и другими утилитами TCP/IP для разрешения имен узлов, находящихся как в локальной, так и в удаленной сети. Кроме того, файл HOSTS может использоваться для разрешения имен NetBIOS (только в Microsoft TCP/IP-32).
Наличие файла HOSTS обязательно на каждом компьютере. Всякая его запись содержит IP-адрес и соответствующие ему одно или несколько имен узлов. По умолчанию в файле HOSTS есть запись с именем localhost.
Файл HOSTS просматривается при каждом обращении к именам узлов, которые считываются из него последовательно, поэтому наиболее часто используемые имена должны находиться в начале файла.
Файл HOSTS можно редактировать при помощи любого текстового редактора. Он находится в каталоге \systemroot\System32\Drivers\Etc.
Всякая запись может содержать до 255 символов, при этом регистр символов не учитывается.
Пример файла HOSTS:
# This file used by Microsoft TCP/IP utilities
127.0.0.1 localhost loopback
102.54.94.97 rhino.microsoft.corn
131.107.2.100 unixhost UNIXHOST # LAN Manager UNIX Host
131.107.3.1 gateway GATEWAY # Default Gateway
Общие сведения о DNS
(Domain Name System)
До 1980 года сеть ARPANET состояла лишь из нескольких сотен компьютеров. Все соответствия имен и адресов компьютеров хранились в одном файле с именем Hosts Этот файл находился на компьютере центра Stanford reseach institute's Network Information Center (SRI-NIC) в Менло-Парк штат Калифорния. Остальные компьютеры этой сети по мере надобности копировали из SRI-NIC файл Hosts на свои узлы.
Первоначально этот файл обновлялся один или два раза в неделю и схема работала хорошо. Однако через несколько лет, когда сеть ARPANET заметно выросла, возникли проблемы:
· файл Hosts стал очень большим
· приходилось обновлять файл несколько раз в день
· поскольку весь сетевой трафик маршрутизировался через SRI-NIC, то поддержка файла Hosts стала камнем преткновения для всей сети
· сетевой трафик через SRI-NIC стал почти неуправляемым
· в Hosts использовалось одноуровневое (flat) пространство имен, поэтому имя каждого компьютера в сети должно было быть уникальным.
Эти и другие проблемы заставили управление ARPANET искать другие способы распространения файла Hosts. В результате была создана доменная система имен - DNS - распределенная база данных, использующая иерархическое (hierarchical) пространство имен.
Доменная система система имен описана в документах RFC 1034 и RFC 1035.
Как работает DNS
В работе DNS участвуют три основных компонента: клиенты DNS, или программы разрешения имен (resolvers) , серверы имен и пространство имен домена.
В простейшем случае DNS-клиент посылает запросы серверу имен. Сервер возвращает либо требуемую информацию, либо указание на другой сервер имен, либо сообщение об отказе, если запрос не может быть удовлетворен.
Доменная система имен - это система управления иерархической распределенной базой данных, использующая технологию клиент - сервер. DNS работает на прикладном уровне (application layer) и использует UDP и TCP/IP как нижележащие протоколы.
Задача базы данных DNS - транслировать имена компьютеров в IP-адреса. Компьютер обращается к DNS, используя имя другого компьютера или домена, а сервер имен выдает соответствующие этому имени IP-адрес.
Сначала DNS-клиенты посылают серверам запросы по протоколу UDP (для повышения производительности), а переключаются на использование TCP только при потере информации.
DNS-клиенты
DNS-клиенты пересылают сообщения между приложениями и серверами имен. Сообщение содержит запрос, например IP-адрес Web-узла. Часто DNS-клиент встроен в приложение или работает на компьютере как библиотечная подпрограмма.
Серверы имен
Серверы имен принимают сообщения от DNS-клиентов и преобразуют имена компьютеров (или доменов) в IP-адреса. Если сервер имен не в состоянии сам сделать это, то он может перенаправить запрос к серверу имен, который сможет разрешить его. Серверы имен сгруппированы по разным уровням -доменам (domains).
Пространство имен домена
Это иерархически упорядоченная структура имен, напоминающая перевернутое дерево
Домены корневого уровня
Домены определяют разные уровни в иерархии. На самом верху - находится корневой домен (root domain). Он использует пустую метку (null lable), но ссылки на корневой домен можно задавать точкой.
Домены верхнего уровня (top-level domains)
· com - коммерческие организации
· edu - образовательные учреждения и университеты
· org - некомерческие организации
· net - сети (крупные сети, входящие в Internet)
· gov - невоенные правительственные учреждения
· mil - военные правительственные учреждения
· num - телефонные номера
· arpa - обратный (reverse) DNS
· xx - двухбуквенные обозначения стран
Список доменов верхнего уровня расширяется. В домены верхнего уровня могут входить узлы и домены второго уровня.
Домены второго уровня
В домены второго уровня входят узлы и другие домены, называемые поддоменами (subdomains). Так, в домен фирмы Microsoft microsoft.com включены как отдельные компьютеры, например ftp.microsoft.com , так и поддомены, например dev.microsoft.com. В последние также могут входить узлы, например ntserver.dev.microsoft.com
Имена узлов
Имена узлов обычно справа дополняются именем домена. Такая запись называется полностью определенным доменным именем (full qualified domain name FQDN). Например: узел Fileserver в домене microsoft.com будет иметь FQDN-имя вида fileserver.microsoft.com
Зоны ответственности
Зоны ответственности (zone of authority) - это часть пространства имен домена, за которую отвечает конкретный сервер имен. Сервер имен хранит IP-адреса для всех имен из зоны его ответственности и обслуживает все запросы клиентов к этим адресам.
Зона ответственности сервера имен охватывает , как минимум один домен, который называют корневым доменом зоны (zone root domain). Зона ответственности может включать и поддомены корневого домена этой зоны. Однако в одну зону необязательно входят все поддомены, расположенные ниже корневого домена этой зоны.
Роли DNS-серверов
DNS- серверы могут выполнять разные задачи. Они могут хранить и поддерживать свои базы данных различными способами. Далее описаны разные способы хранения данных своей зоны.
Основной сервер имен
Основной сервер имен извлекает информацию из локальных файлов. Изменения в параметрах зоны, например добавление узла или домена , выполняются на основном сервере имен.
Резервный сервер имен
Резервный сервер имен получает информацию о своей зоне от других серверов которые ответственны за данную зону. Такой способ получения информации через сеть, называют зонной передачей (zone transfer).
Существует три основные причины, по которым следует создавать резервные серверы имен.
· Избыточность - Вам необходимы, как минимум, один основной и один резервный сервер имен на каждую зону. Компьютеры должны быть как можно более независимы.
· Ускоренный доступ для удаленных клиентов - если у Вас есть несколько удаленных клиентов, то наличие резервных серверов имен (или других основных серверов имен в поддоменах) освободит их от использования низкоскоростных линий при распознавании имен.
· Снижение нагрузки - резервные серверы имен уменьшают загруженность основных серверов.
Поскольку информация о разных зонах хранится в разных файлах, то разделение серверов на основные и резервные значимо только в пределах зоны. Другими словами, данный DNS-сервер может быть основным по отношению к одной зоне и резервным по отношению к другой.
Главный сервер имен
При определении DNS-сервера на роль резервного сервера имен в данной зоне Вы должны указать DNS-сервер, от которого будет поступать зонная информация. Источник такой информации для резервного сервера имен в иерархии DNS называют главным сервером имен (master name server). Главный сервер имен может быть как основным, так и резервным DNS-сервером в своей зоне. При запуске резервный DNS-сервер связывается со своим главным сервером имен и запрашивает зонную передачу.
Кэширующий DNS-сервер
Все DNS-серверы кэшируют запросы, на которые они отвечают. Кэширующие - это DNS-серверы, которые только перенаправляют запросы, кэшируют ответы и возвращают результаты. Другими словами, они не отвечают ни за какие домены (на них информация о зонах не хранится), а содержат лишь информацию, которая попала в кэш из ответов на запросы.
Обдумывая целесообразность использования такого DNS-сервера в Вашей организации, обратите внимание на то, что при начальном запуске кэш не содержит информации - она накапливается при обслуживании запросов. При этом отсутствует зональная передача и сильно снижается объем сетевого графика. Это важно, если Вы работаете с низкоскоростными линиями связи.
Разрешение имен в DNS
Существует три типа запросов, которые клиент может направить к DNS-серверу: рекурсивный (recursive), итеративный (iterative) и обратный (inverse).
Рекурсивные запросы
DNS-сервер обязательно отвечает на рекурсивный запрос, посылая либо запрошенную информацию, либо сообщение об ошибке. Последнее означает, что запрошенные данные отсутствуют или указанного имени домена не существует. При этом DNS-сервер не может перенаправить клиента к другому DNS-серверу.
Итеративные запросы
На итеративный запрос DNS-сервер выдает наилучший ответ из имеющихся у него. В нем может содержаться разрешенное имя или ссылка на другой DNS-сервер.
Рассмотрим следующий пример рекурсивного и итеративного запросов: клиент, находясь на работе, запрашивает у DNS-сервера IP-адрес, соответствующий узлу www.whitehouse.gov.
1. DNS-клиент посылает локальному DNS-серверу рекурсивный запрос, в котором просит определить IP-адрес для узла www.whitehouse.gov. Локальный сервер имен отвечает за распознавание имени и не может перенаправить клиента к другому DNS-серверу.
2. Локальный DNS-сервер просматривает свои зоны и не находит зону, содержащую указанное имя домена. Тогда он посылает к корневому серверу имен итеративный запрос об узле www.whitehouse.gov.
3. Корневой DNS-сервер, ответственный за корневой домен, возвращает IP-адрес сервера имен для домена верхнего уровня - .gov.
4. Локальный DNS-сервер посылает DNS-серверу домена .gov итеративный запрос о www.whitehouse.gov.
5. DNS-сервер домена .gov возвращает IP-адрес сервера имен, обслуживающего домен whitehouse.gov.
6. Локальный DNS-сервер посылает DNS-серверу домена whitehouse.gov итеративный запрос о www.whitehouse.gov.
7. DNS-сервер домена whitehouse.gov возвращает IP-адрес, соответствующий www. whitehouse.gov.
8. Локальный DNS-сервер посылает клиенту IP-адрес для www.whitehouse.gov.
Обратные запросы
При обратном запросе клиент пытается у DNS-сервера узнать имя узла, соответствующего известному IP-адресу. Вообще-то, в пространстве имен DNS не установлено соответствие IP-адресов именам, и лишь сплошной просмотр всех доменов позволяет получить правильный ответ.
Чтобы избежать тотального просмотра всех доменов при обслуживании обратного запроса, был создан специальный домен, in-addr.arpa. Имена узлов этого домена с дают с записью IP-адреса в виде четырех десятичных чисел, разделенньк точкой. Но поскольку IP-адреса уточняются слева направо, а доменные имена справа налево, то при построении домена in-addr.arpa необходимо изменить порядок следования чисел IР-адреса. Согласно этому, управление нижележащими членами домена in-addr.arpa можно передать организациям, которым выделяются IP-адреса классов А, В и С.
В домен in-addr.arpa при его создании добавляются специальные ресурсы -указателъные записи (pointer records, PTR), связывающие IP-адрес с именем узла. Например, чтобы определить имя узла, соответствующее IP-адресу 157.55.200.51, клиент обращается к DNS-серверу с запросом указательной записи для 51.200.55.157. in-addr.arpa. Найденная указательная запись содержит имя узла и соответствующий IP-адрес 157.55.200.51. Эта информация отправляется обратно клиенту. В задачи администрирования DNS-сервера входит создание указательных записей для узлов данного домена.
Кэширование и время TTL
При обработке рекурсивного запроса иногда необходимо для получения ответа посылать несколько сообщений. Сервер имен сохраняет в кэше всю получаемую им информацию, но лишь на время, указанное в возвращаемых данных. Этот интервал называют временем жизни (time to live, TTL). Его определяет администратор DNS-сервера той зоны, в которой находятся указанные данные. Если информация о домене не изменяется часто, то меньшее значение TTL гарантирует, что данные во всей сети не успевают устаревать. Однако это сильно загружает DNS-серверы.
Как только информация попадает в кэш, начинается обратный отсчет TTL. По истечении TTL она будет удалена из кэша DNS-сервера. DNS-клиенты также имеют кэш и учитывают TTL, поэтому они будут знать, когда данные устареют.