Системы имен, принятые в NetWare, Microsoft и Internet

Размещено на http://www.allbest.ru/

Введение

На ранней стадии разработки сети Internet существовали методы разрешения символических имен, таких как microsoft.com и course.com, в числовые IP-адреса, которые полностью основывались на статических текстовых файлах под названием HOSTS, в которых содержался список всех известных имен хостов, возможных псевдонимов и соответствующих числовых IP-адресов. Реализация этого подхода была чрезвычайно проста, и он был вполне применим в небольших масштабах; тем не менее, к 1982 году в сети APRANET (предшественница Internet, разработка которой финансировалась правительством США) было уже довольно много хостов, в результате чего стало сложно обеспечивать совместимость всех файлов HOSTS, которые позволяли пользователям преобразовывать все доменные имена в соответствующие IP-адреса, и наоборот.

Как только известные хосты (и доменные имена) стали исчисляться тысячами, поддержка и распространение текущего файла HOSTS по всей сети Internet превратились в трудноразрешимую проблему. Системные администраторы начали отказываться производить ежедневную загрузку файлов, все увеличивающихся в размере, а окружение разрасталось быстрее, чем предусматривали возможности статических методов обработки.

Чтобы разрешить столь сложную ситуацию, Пол Мокапетрис (Paul Mockapetris) составил первоначальные документы RFC 882 и RFC 883, посвященные службе DNS, а в 1984 году он же создал первую эталонную реализацию DNS, назвав ее JEEVES. В 1988 году Кевин Данлеп (Kevin Dunlap) осуществил другую реализацию службы DNS в среде BSD UNIX 4.3; она получила название BIND (Berkley Internet Name Domain). Впоследствии BIND стала наиболее распространенной из применяемых реализаций DNS;

1 Служба доменных имен (Domain Name System, DNS)

DNS (Domain Name System) - протокол и служба прикладного уровня TCP/IP, управляющая распределенной по всей сети Internet базой данных символических имен и числовых IP-адресов.

DNS обеспечивает жизненно важную возможность преобразования символических доменных имен, таких как microsoft.com и course.com, в соответствующие числовые IP-адреса (207.46.230.229 и 195.95.72.8 соответственно). Не будь такой службы преобразования, людям пришлось бы запоминать числовые IP-адреса всех узлов Internet. Кроме того, DNS поддерживает другие службы -- например, она преобразовывает адреса электронной почты типа etittel@lanw.com в IP-адреса серверов, обрабатывающих соответствующий трафик. Можно с полной уверенностью утверждать, что без службы DNS популярность сети Internet была бы несравнима с сегодняшней.

1.1 Структура баз данных DNS

Структура базы данных DNS отражает структуру самого пространства присваиваемых имен доменов. Это древовидная структура (tree structure) (на самом деле, это дерево перевернуто вверх дном, т. к. корень (root) обычно изображается вверху схемы). Тот же тип структуры характерен для жесткого диска, в корне которого изображается буква, представляющая сам диск, а от нее "ветвятся" многочисленные уровни каталогов и подкаталогов.

В пространстве присваиваемых имен домены соприкасаются в корне, который обозначается символом точки ".". Прямо под корнем находятся первичные домены (домены верхнего уровня). В Соединенных Штатах домены верхнего уровня обычно представлены следующими трехбуквенными кодами.

- .соm -- в основном используется коммерческими организациями;

- .edu -- используется образовательными учреждениями: школами, колледжами и университетами;

- .gov -- используется федеральным правительством Соединенных Штатов;

- .mil -- применяется военными структурами Соединенных Штатов;

- .net -- в основном применяется поставщиками услуг сети Internet и сетевыми организациями;

- .org -- в основном применяется некоммерческими организациями, ассоциациями и профессиональными сообществами.

Кроме того, существуют домены, оканчивающиеся двух- или трехбуквенными кодами стран, которые определены в стандарте 3166 Международной организации по стандартизации (ISO). В этой системе код .us представляет Соединенные Штаты, .са -- Канаду, fr -- Францию, .de-- Германию (Deutschland), .ru - Российскую Федерацию, и т. д.

Иерархии доменов организаций расположены ниже доменов верхнего уровня. Для небольших компаний они могут состоять из одного уровня доменных имен, например lanw.com или podbooks.com. Что касается крупных корпораций, у них могут быть домены, состоящие из четырех и более компонентов, каждый из которых отделен от соседнего точкой. Древовидная схема одного из доменных имен фирмы IBM изображена на рис 1.1.

Рисунок 1.1 - Древовидная схема доменного имени houns54.clearlake.com компании IBM

Пятнадцать корневых серверов имен представляют собой вершину всемирной иерархии DNS. Они являются последней инстанцией при поиске имен, которые невозможно разрешить другими средствами.

Доменные имена начинаются в нижней части дерева и указываются последовательно по мере повышения их положения на схеме. После каждого имени ставится точка, отделяющая его от других имен (точнее говоря, частей имени). Таким образом, следующая схема изображает имя houns54.clearlake.ibm.com. Необходимо отметить, что эта последняя точка (которая обозначает корневой уровень иерархии DNS, а не конец выражения) очень важна при составлении полностью определенного имени домена (Fully Qualified Domain Name, FQDN). В действительности, FQDN содержит все элементы доменного имени, после каждого из которых ставится точка, причем последняя точка символизирует корневой уровень иерархии DNS.

Чтобы система DNS могла работать, необходимо выполнение еще одного существенного условия -- каждому уникальному доменному имени должен соответствовать хотя бы один действительный IP-адрес. На сегодняшний день поддерживание таких соответствий является первичной функцией службы DNS.

1.2 Делегирование полномочий DNS

Каждая позиция в пространстве присваиваемых имен службы DNS соотносится с каким-либо узлом на графическом дереве, изображающем его структуру; очень небольшая часть такой структуры изображена на рисунке 1.1. Каждый узел этого дерева образует корень нового поддерева в общей иерархии. Каждое такое поддерево олицетворяет сегмент базы данных (DNS database segment). Его также можно назвать доменом в глобальном пространстве присваиваемых имен доменов.

Мощность и гибкость службы DNS обусловлена ее способностью в случае необходимости расчленять дерево и создавать контейнеры информации из базы данных. Таким образом, домены (скажем, ibm.com) можно разделить на субдомены (subdomains) (например, clearlake.ibm.com). В результате появляется возможность локального управления сегментами базы данных; по существу, это -- вид делегирования полномочий (delegation of authority). В то время как домены нужно регистрировать (за плату) в центральной организации, субдомены могут с легкостью создавать локальные системные администраторы, причем делают они это совершенно бесплатно.

Проблема управления огромным и сложным пространством имен (каковым является сеть Internet) облегчается посредством его разделения на контейнеры для отдельных комплексов DNS-серверов, адресов, пользователей и компьютеров; эти контейнеры довольно малы, и потому управлять ими под силу одному или двум сетевым администраторам.

Кроме того, каждое действительное доменное имя в конечном итоге располагается в определенной базе данных DNS, причем данной записью заведует один конкретный сервер.

Компании и организации масштаба IBM или военно-воздушных сил США охотно согласятся с тем, что некоторые домены слишком велики и сложны, чтобы их можно было разместить в одном контейнере базы данных. Это основная причина, по которой служба DNS позволяет делегировать полномочия относительно различных субдоменов DNS-серверам, находящимся ниже пространства присваиваемых имен домена. Это можно воспринимать как цифровую форму передачи ответственности на более низкий уровень иерархии, при которой не искажается ни модельное представление, ни фактическая линия поведения службы DNS.

На самом деле, делегирование полномочий реализуется в виде передачи полномочий на субдомены другим серверам имен доменов, которые обычно находятся в других местах, но в границах организаций, в том числе географических. После осуществления делегирования в базе данных сервера имен ibm.com появляются NS-записи, указывающие на серверы имен, ответственные за конкретные субдомены. Кроме того, в базе данных сервера ibm.com могут содержаться отдельные записи для адресов, которые не попадают в границы каких-либо субдоменов. Это могут быть отдельные адреса и другая информация в штаб-квартире корпорации, или же данные о группах персонала, у которых нет постоянных сайтов. Это довольно гибкая структура, которую может применить практически любая организация или компания.

Устройство всемирной базы данных DNS позволяет серверам имен указывать на другие серверы имен, когда они не обладают полномочиями на конкретные субдомены. Таким образом, значительная часть пространства присваиваемых имен доменов, которое коллективно управляется DNS -серверами, состоит из перечисленных далее типов, указывающих на определенные серверы имен, наделенные полномочиями по управлению конкретными субдоменами. Именно это позволяет серверам имен осуществлять переадресацию нужных DNS -записей, когда запросы на разрешение имен исходят из корневого уровня иерархии DNS.

1.3 Базы данных служб имен

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

Обращаясь к истокам службы DNS, можно охарактеризовать содержимое файлов баз данных, формирующих данные DNS, как способ преобразования данных файлов HOSTS в эквивалентные данные службы DNS, а затем добавления информации, необходимой для самой системы DNS.

v HOSTS -- специальный текстовый файл с перечнем известных доменных имен и соответствующих им IP-адресов, представляющий собой статический метод разрешения доменных имен. До создания DNS файлы HOSTS были единственным средством разрешения имен в сети ARPANET -- предшественнице Internet.

Файлы, которые связывают имена хостов с адресами, обычно обозначаются как domain.dns, где domain -- это локальное имя домена или субдомена для зоны, относящейся к DNS -серверу. К примеру, DNS -сервер для домена lanw.com называется lanw.com.dns.

Файлы, связывающие адреса с доменными именами при операциях обратного поиска, как правило, обозначаются как addr.in-addr.arpa.dns, где addr -- это номер сети домена в обратном порядке без замыкающих нулей. Для домена lanw.com, чей номер сети -- 206.224.65.0, файл называется 65.224.206.in-addr.arpa.dns. Иногда эти файлы также обозначаются как in-addr.arpa в соответствии с меткой, помещаемой в конец каждого обратного адреса в записях указателя файла. Следует отметить, что в других реализациях службы DNS (в первую очередь, в BIND) принято другое соглашение относительно именования таких файлов, но эти файлы, вне зависимости от их названия, в любом случае должны работать. Собственно говоря, в таких файлах содержится статическая копия базы данных DNS в том виде, в котором она существовала в момент ее копирования на диск, или перед выключением DNS -сервера.

v BIND (Berkley Internet Name Domain, служба доменных имен в сети Internet) -- BIND на сегодняшний день является наиболее распространенной в сети Internet реализацией программного обеспечения DNS-сервера. Исходно была частью операционной системы BSD UNIX 4.3, но сегодня существуют реализации BIND почти для всех платформ, включая Windows NT и Windows 2000.

Для каждой зоны DNS должны существовать записи SOA и NS, а также записи об именах хостов или адресов в данной зоне. Адресные записи (А) содержат данные о соответствии имен адресам, в то время как записи указателей (PTR) предоставляют обратные данные о соответствии адресов именам. Записи канонических имен (CNAME) позволяют определить псевдонимы для хостов в данной зоне, но это делается в первую очередь для того, чтобы помещать новые данные в файлы зон было удобнее. Так, для субдомена houns54.cleariake.ibm.com можно создать псевдоним h54.clearlake.ibm.com, что позволит вводить 21 символ вместо 25-ти.

1.3.1 Запись начала полномочий (SOA)

Первой записью в любом файле .dns (имеются в виду как файлы domain.dns, так и addr.iii-addr.arpa.dns) должна быть запись SOA. Она определяет текущий сервер имен (или другой сервер имен в том же домене или субдомене) как лучший источник информации для данной зоны. Хоть вторичные серверы имен и получают свои данные от первичного сервера в домене, но и те, и другие в своих собственных записях SOA могут назначать себя ответственными. В действительности, именно эта возможность позволяет осуществлять выравнивание нагрузки между первичным, с одной стороны, и одним или несколькими вторичными DNS-серверами в домене.

Ниже для примера приведена запись SOA со всем содержимым.

tree.com. IN SOA apple.tree.com. sue.pear.tree.com

(1 // порядок

10800 // обновление через 3 часа

3600 // повторная попытка через 1 час

604800 // истечение через 1 неделю

864 00 // минимальное время жизни -- 1 день.)

Рассмотрим данную запись детально.

tree.com. IN SOA apple. tree. соm. - это имя домена, к которому применим данный файл зоны; IN означает, что запись принадлежит к классу Internet типов записей; SOA указывает, что запись относится к типу записей начала полномочий; apple.tree.com. - это полностью определенное имя домена (FQDN) для первичного сервера имен домена; наконец, sue.pear.tree.com - это форма написания адреса электронной почты sue@pear.tree.com, принадлежащего администратору, ответственному за этот сервер. Все остальные записи, присутствующие между открывающей и закрывающей скобками, представляют собой специальные атрибуты этой индивидуальной записи SOA, перечисленные в следующих пяти элементах списка.

- порядок (serial). Это беззнаковое 32-битное число, представляющее первоначальное значение (именно его вторичные серверы имен используют для сравнения со значением на первичном сервере; исходя из результатов этого сравнения, они решают, нужно ли обновлять записи). Это число возрастает каждый раз, когда значение на первичном сервере имен обновляется (это значение копируется на вторичные серверы имен в тот момент, когда они выполняют проверку необходимости обновления своих записей).

- обновление (refresh). Период времени в секундах, который должен пройти перед обновлением базы данных зоны (10 800 секунд -- это 3 часа, что и указано в поле комментария). Это гарантирует, что информация на всех вторичных серверах будет не совпадать с данными на первичном сервере не более, чем в течение трех часов.

- повторная попытка (retry). Период времени в секундах, который должен пройти перед обновлением, когда предыдущая попытка была неудачной (3600 секунд -- это 1 час).

- истечение (expire). Здесь указывается период времени в секундах, который должен пройти перед тем, как база данных зоны утратит статус ответственной. Это значение совпадает со значением счетчика, который позволяет DNS-серверу вычислить, сколько времени прошло с момента последнего обновления.

- минимальное время жизни (minimum TTL). Здесь указывается, в течение какого времени любая запись ресурса должна существовать в кэше другого неответственного DNS-сервера. Это значение определяет, как долго кэшированная запись может сохраняться на DNS-серверах вне зоны, из которой данная запись исходи (86400 секунд - это 24 часа, или 1 день).

Далее рассмотрим записи А и CNAME.

1.3.2 Адресные записи и записи канонических имен

В следующем примере продемонстрированы способы применения записей А и CNAME, главным образом в файлах domain.dns (к примеру, tree.com.dns для домена tree.com).

// адреса хостов

localhost.tree.com. IN А 127.0.0.1

pear.tree.com. IN А 172.16.1.2

apple.tree.com. IN А 172.16.1.3

peach.tree.com. IN А 172.16.1.4

// многоканальный хост

hedge.tree.com. IN А 172.16.1.1

hedge.tree.com. IN А 172.16.2.1

// псевдонимы

pr.tree.com IN CNAME pear.tree.com

h.tree.com IN CNAME hedge.tree.com

a.tree.com IN CNAME apple.tree.com

hl.tree.com IN CNAME 172.16.1.1

h2.tree.com IN CNAME 172.16.2.1

Имея в виду вышеприведенный текст, рассмотрим следующие пояснения.

- localhost.tree.com. IN А 127.0.0.1

Здесь задается адрес для полностью определенного доменного имени "localhost", которое преобразуется в localhost.tree.com., эквивалентный адресу обратной связи (loopback address). Это значение необходимо для того, чтобы пользователи могли указывать в командах и запросах IP имя "localhost" или "loopback".

- pear.tree.com. IN А 172.16.1.2

Здесь задается адрес для полностью определенного доменного имени pear.tree.com., эквивалентного IP-адресу 172.16.1.2.

- hl.tree.com IN CNAME 172.16.1.1

hl.tree.com IN CNAME 172.17.1.1

Эта техника важна постольку, поскольку она позволяет получать доступ к отдельным сетевым интерфейсам по именам на маршрутизаторе или на любом другом IP-хосте, который присоединен к многочисленным подсетям посредством столь же многочисленных сетевых интерфейсов. (Такие устройства называются многоканальными (multi-homed)) Это может быть существенно при запрашивании SNMP-статистики или в PING-запросах на отдельные адреса интерфейсов. По умолчанию, когда определено несколько записей на один домен (как должно быть применительно к многоканальным устройствам), DNS обращается лишь к первому IP-адресу хоста. Эта методика, позволяет связывать имя с каждым отдельным интерфейсом, не запоминая его индивидуальный числовой IP-адрес.

Видно, что в записи CNAME сначала указывается псевдоним, а потом уже -- реальное доменное имя; кроме того, ни одно доменное имя не завершается точкой (и поэтому эти доменные имена не являются полностью определенными, в отличие от тех, что указываются в записях А и PTR).

1.3.3 Соответствие адресов именам

Записи в файле db.addr обеспечивают обратный поиск DNS (при котором задается IP-адрес, а предполагается определить соответствующее ему доменное имя).

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

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

Приведем пример файла под названием I6.172.in-addr.arpa.dns. Адреса, указанные в файле tree.com.dns, приводятся в обратном порядке. Кроме того, каждый обратный адрес завершается строкой . in-addr-arpa., включая точку на конце.

Дело в том, что все эти адреса входят в пространство IP-адресов, определенное для сети Internet, изначально называвшейся ARPANET.

1.1.16.172.in-addr-arpa. IN PTR hedge.tree.com

2.1.16.172.in-addr-arpa. IN PTR pear.tree.com

3.1.16.172.in-addr-arpa. IN PTR apple.tree.com

4.1.16.172.in-addr-arpa. IN PTR peach.tree.com

Видим прямое соответствие адресов слева доменным именам справа. Для каждой подсети есть отдельный файл такого типа.

1.4 Реализация DNS

Реализации службы DNS преследуют две основные цели. Одна из них -- предоставление конкретным пользователям служб разрешения имен, чтобы они могли обращаться к службам, предлагаемым во всех других частях глобальной сети; другая -- обеспечение надежного соответствия имен хостов и IP-адресов, чтобы пользователи, где бы они ни находились, могли получать доступ к службам, предоставляемым на конкретном Web-, FTP- или почтовом сервере. Несмотря на то, что с технической точки зрения такие службы действуют одинаково, их администрирование часто различается.

Основная причина этого состоит в том, что технические средства, применяемые для реализации DNS-разрешения для пользователей сети, направлены на обеспечение доступности и высокой производительности применительно к относительно небольшому количеству соответствий имен хостов и IP-адресов. Эти соответствия обычно довольно стабильны, так как используют зарегистрированные Internet-адреса, хотя такие продукты часто содержат функции, позволяющие применять службу DNS для выравнивания нагрузки между локальными и географически рассредоточенными серверами. DNS -серверы, предназначенные для внутреннего использования, зачастую направлены на ослабление трудностей администрирования посредством DHCP, WINS, Active Directory и других служб протокола LDAP (Lightweight Directory Access Protocol, облегченный протокол службы каталогов) и отслеживание чрезвычайно изменчивого пространства частных IP-адресов, в котором происходит постоянная смена пользователей.

Другое важное различие -- в именовании таких систем. Чтобы облегчить управление, многие администраторы присваивают рабочим станциям имена, состоящие из имен пользователей или подразделений. К примеру, имя компьютера с системой Windows (которое на самом деле является именем NetBIOS) может звучать как jsmith или jsmith-acct, если его пользователя зовут Джон Смит (John Smith), и он работает в бухгалтерии (Accounting Department). Эта информация может автоматически передаваться системе DNS для создания А-записи jsmith-acct.ny.mycompany.com. Кроме того, распространенной практикой является описательное именование серверов. Очевидно, что такая информация не должна быть доступна всем пользователям сети Internet. Руководствуясь соображениями безопасности, необходимо проводить разделение внутреннего и внешнего DNS -серверов.

1.5 Недостатки DNS

Несмотря на мощные возможности службы DNS и многие ее преимущества, и ей присущи некоторые недостатки. Основной такой недостаток состоит в том, что для обновления баз данных DNS обычно требуется, чтобы квалифицированный администратор производил все операции непосредственно с файлами базы данных DNS, или пользовался специализированными средствами (например, утилитой NSUPDATE в среде UNIX). Требование обновления баз данных службы DNS делает такие обновления непростой задачей. С выходом операционной системы Windows 2000 компания Microsoft представила на суд публики реализацию динамической системы DNS (Dynamic DNS, DDNS), но для того, чтобы она функционировала, реализация Windows DNS должна быть связана с базой данных Active Directory (с ней же должна быть связана и служба DHCP).

v DHCP - это сетевая служба и протокол Прикладного уровня TCP/IP, позволяющие сетевым администраторам настраивать серверы таким образом, чтобы они осуществляли распределение и управление группами IP-адресов рабочих станций, настольных компьютеров и других клиентских машин, не требующих присвоения фиксированных IP-адресов. Так же DHCP может предоставлять клиентам важную информацию, касающуюся конфигурации протокола IP, включая маску подсети, адрес локального IP-шлюза (маршрутизатора) и даже, если в этом есть необходимость, данные служб DNS и WINS. Собственно говоря, основное назначение протокола DHCP состоит в том, чтобы обеспечить администрирование конфигурационных данных и присвоение клиентам IP-адресов посредством центрального сервера, не принуждая сетевых администраторов вручную настраивать каждую отдельную клиентскую систему.

В сущности, при этом система DNS не требует осуществления каких-либо изменений, кроме подсоединения к Active Directory. Active Directory с помощью DHCP отслеживает изменения в отношениях доменных имен и адресов, и, когда эти изменения происходят, подает на DNS-сервер необходимые запросы на обновление. Таким образом, Active Directory автоматизирует все те задачи, которые в других условиях приходится выполнять администратору. В настоящее время эта реализация работает только в операционных системах Microsoft. Более стандартные реализации DDNS применяют средства обновления, отраженные в документе RFC 2136, но пока они не могут обеспечить взаимодействия с реализацией Microsoft DNS в операционной системе Windows 2000. Даже принимая во внимание такие усовершенствования системы DNS, в некоторых случаях до сих пор требуется прямое взаимодействие с файлами зон DNS -- посредством редактирования этих файлов в ASCII-редакторах, с помощью утилит командной строки вроде NSUPDATE или через графический интерфейс (как в Windows-реализации).

Другую проблему, оказывающую пагубное влияние на систему DNS, можно назвать "задержкой распространения". Дело в том, что слишком много времени требуется на синхронизацию кэшированных значений с изменениями, произведенными в ответственных базах данных, содержащих "оригиналы" DNS-записей. Именно поэтому поставщики услуг регулярно предупреждают своих клиентов о том, что до полноценного действия преобразования имени в адрес в сети Internet (как, например, при переносе домена от одного провайдера к другому, что всегда означает изменение IP-адреса, связанного с этим доменным именем) может пройти до трех дней.

Эта задержка является следствием действия значения времени жизни (Time to Live, TTL) записи базы данных, которая при внесении изменений может существовать дольше положенного периода.

2 Система NetBIOS

NetBIOS (Network Basic Input/Output System) - сетевая базовая система ввода/вывода. Изначально NetBIOS предназначалась для именования компьютеров, затем -- пользователей и, наконец, -- других ресурсов локальной сети. Впоследствии понятия рабочих групп (workgroups) и доменов, введенные в Windows-сети, также реализовывались посредством имен NetBIOS. Исходно система NetBIOS была не протоколом, а программным интерфейсом приложения (Application Programming Interface, API), применяемым для обращения к сетевым ресурсам. В качестве транспортного протокола как такового выступал расширенный пользовательский интерфейс NetBIOS (NetBIOS Enhanced User Interface, NetBEUI), объединяя 2--5 уровни сетевой эталонной модели ISO/OSI (эталонной модели OSI).

У каждого ресурса NetBIOS есть 15-символьное имя, предваряющее односимвольный (2-байтный) код, обозначающий тип этого ресурса. Так получилось, что возможность совместного использования ресурсов NetBIOS вне локальной сети так и не была обеспечена. Простая структура пространства имен NetBIOS не содержит средств для того, чтобы провести различие между, например, "Джоном в IBM Almaden" и "Джоном в IBM Armonk"; им можно лишь присвоить уникальные имена. Несмотря на добавление групповых имен для доменов и рабочих групп Windows, пространство имен NetBIOS не выстроено в четкую иерархию. С точки зрения NetBIOS, есть только одна сеть -- та, в которой эта система находится. В отсутствие сетевого компонента (наподобие того, что присутствует в IP-адресе) маршрутизация NetBIOS и NetBEUI в принципе невозможна. Собственно говоря, заданная конфигурация большинства маршрутизаторов запрещает им маршрутизировать пакеты NetBEUI. Это именно то, что нужно, учитывать, когда ресурс NetBIOS с именем "John" (Джон) в одной сети может кардинально отличаться от ресурса "John" (Джон) в другой сети, но различия между ними не проводится.

В начале 1990-х в компании Novell была разработана схема маршрутизации трафика NetBIOS путем его инкапсуляции в протокол IPX. В результате в сетях NetWare IPX-представление сетевой иерархии предоставило возможность преодолеть ограничения NetBIOS. Не заставила себя ждать реакция компании Microsoft, предложившая инкапсуляцию трафика NetBIOS в UDP- или TCP-пакеты, работающих на основе протокола IP.

Маршрутизация трафика NetBIOS в сторонние сети предполагает возможность идентификации компьютера, предлагающего эти ресурсы, -- для разрешения имени NetBIOS в конкретный процесс на конкретной машине. В 1987 году компанией Microsoft было предложено использование серверов имен NetBIOS (NetBIOS Name Servers, NBNS). Этот подход был реализован в WINS-сервере -- сначала в Windows NT Server, а потом и в Windows 2000 Server.

NetBIOS п Windows 2000

С самого начала система NetBIOS со своими расширениями и производными составляла основу организации одноранговых Windows-сетей. В компании Microsoft делались попытки преодолеть исходные ограничения NetBIOS, однако желание соблюсти обратную совместимость означало невозможность полного отказа от NetBIOS и NetBEUI. Даже последние достижения в технологиях организации сетей Windows, такие как протоколы CIFS и SMB, основаны на ядре NetBIOS.

Windows 2000 -- это первая операционная система Microsoft, в которой предпочтительным методом разрешения имен и адресов является служба DNS, а не производные NetBIOS. Но даже в этих условиях DNS-службы Windows 2000 можно интегрировать с WINS-службами, что гарантирует возможность взаимодействия со старыми системами Windows.

Есть множество способов конфигурации Windows 2000, которые позволяют приспособиться к различным сетевым средам. В сети, в которой используется только Windows 2000, разрешение сетевых IP-имен и адресов можно осуществлять с помощью служб Active Directory (AD) и DNS. В Active Directory применяется Microsoft-реализация облегченного протокола службы' каталогов (Lightweight Directory Access Protocol, LDAP). Тем не менее, для совместного со старыми версиями Windows использования ресурсов необходимо включить разрешение имен NetBIOS. В зависимости от возраста операционных систем и типов взаимодействия между ними, может потребоваться установка и конфигурация NetBEUI, который теперь называется фреймовым протоколом NetBIOS (NetBIOS Frame, NBF); это позволит обеспечить обратную совместимость.

Более 15 лет система NetBIOS подвергалась бесчисленным обновлениям, инкапсуляциям, модификациям и усовершенствованиям, в результате чего NetBIOS приобретала новые функции.

2.1 Как работает NetBIOS

NetBIOS поддерживает список уникальных имен сетевых ресурсов, обеспечивает службы установления, охраны и разрешения этих имен, осуществляет передачу сообщений между приложениями, использующими эти сетевые ресурсы; среди именованных ресурсов -- файлы, службы (процессы), пользователи, компьютеры, домены и рабочие группы Windows. NetBIOS гарантирует правильность, актуальность и уникальность имен и обеспечивает программные интерфейсы приложений (API) доступом к этим ресурсам. Для обращения к именованному ресурсу приложение должно совершить запрос к интерфейсу NetBIOS или найти имена доступных ресурсов. В зависимости от конфигураций NetBIOS на конкретных машинах эта система может предпринимать различные действия для разрешения имен в адреса. Затем она может отправлять сообщения для запрашивания именованного ресурса или открывать и поддерживать сеанс.

Трафик NetBIOS состоит из фреймов NetBIOS одного из двух типов: дейтаграмм или сеансовых фреймов. Дейтаграммы применяются в трафике для "объявления" без установления соединения или в запросах и ответах, которые не требуют учреждения и поддержки надежного соединения между двумя хостами. Кроме того, в виде дейтаграмм передаются службы имен и службы дейтаграмм (datagram services) NetBIOS. Сеансы NetBIOS используются в ситуациях, в которых необходимо установление надежного соединения, -- например, во время взаимодействия с процессом, работающим на другом хосте.

NetBIOS может предоставлять действующий протокол (в форме протокола NBF или NetBEUI), применяемый для транспортировки NetBIOS-сообщений. Когда сообщения пересылаются посредством протокола NBF или NetBEUI, они инкапсулируются непосредственно в части IEEE 802.2 LLC сетевого фрейма данных. Распределенный интерфейс передачи данных по волоконно-оптическим каналам (Fiber Distributed Data Interface, FDDI) и все сетевые протоколы серии IEEE 802 поддерживают стандарт управления логическим соединением (Logical Link Control, LLC) 802.2. Серия сетевых протоколов IEEE 802 состоит из 802.11 (беспроводные локальные сети), 802.3 (Ethernet) и 802.5 (Token Ring).

Когда NetBIOS, как и служба NetBT, работает посредством TCP/IP, дейтаграммы пересылаются в UDP-пакетах, а сеансовые фреймы -- в ТСР-пакетах. Протокол UDP функционирует без установления соединения, в то время как протокол TCP создает и поддерживает надежное соединение, лучше согласующееся с потребностями сеансов NetBIOS.

2.2 Регистрация и поддержка имен NetBIOS

Утверждение существования имени и его принадлежности конкретному компьютеру, пользователю, процессу или группе называется регистрацией имени. Когда компьютер (в документации Microsoft NetBIOS он называется "конечным узлом") или пользователь подсоединяются к сети NetBIOS или когда запускается процесс с именем NetBIOS, они пытаются зарегистрировать свое имя посредством отсылки пакета запроса на регистрацию имени (Name Registration Request packet). В зависимости от конфигурации узла и сети, этот пакет может отсылаться как широковещательный или однонаправленный пакет WINS-серверу или обоими указанными способами. Если запрошенное имя уже затребовано другим узлом сети, то,WINS-сервер (или существующий держатель имени) отказывает инициатору запроса в использовании этого имени, отправляя ему отрицательный ответ на запрос регистрации имени (Name Registration Reply).

2.3 Файл LMHOSTS и кэш имен NetBIOS

Кэш имен NetBIOS -- это временный файл, размещающийся в памяти и устанавливающий соответствие имен NetBIOS и IP-адресов. Имена добавляются в кэш имен NetBIOS по мере их обнаружения в ходе разрешения и запуска компьютера, и именно тогда кэш имен инициализируется посредством считывания файла LMHOSTS. По умолчанию время хранения записей в кэше имен NetBIOS ограничивается 10 минутами. Параметр лимита времени можно установить в реестре.

LMHOSTS -- это текстовый файл, который хранится в каталоге <корень windows>\system32\drivers\etc. В нем перечисляются имена NetBIOS и связанные с ними IP-адреса. Файл LMHOSTS составляется по образцу файла HOSTS для протокола IP в системах BSD UNIX. Его базовая структура, применение и синтаксис соответствуют файлу HOSTS, но в нем отражаются функции, уникальные для NetBIOS. К примеру, символы, которые не поддерживались в исходной реализации DNS, в файле LMHOSTS можно представить, заключив имя в кавычки, а символы, отсутствующие в DNS, -- в виде шестнадцатеричного значения ("FRANK \0xl4").

В файле LMHOSTS можно выбирать, какие имена предварительно загружать в кэш имен NetBIOS, включать дополнительные и/или альтернативные файлы LMHOSTS по обращению, обозначения доменов и имена уникальных ресурсов. Каждая из этих функций обеспечивается своим синтаксисом, в том числе зарезервированными словами. В качестве примера вы можете ознакомиться с файлом LMHOSTS, присутствующим на любом компьютере с установленной операционной системой Windows 2000.

Создавать и редактировать файлы LMHOSTS позволяет любой редактор простого текста. При каждом поиске по файлу LMHOSTS он анализируется полностью -- вместе со строками комментариев. Ограничивая объем этого файла, можно улучшить производительность.

Файл LMHOSTS -- это статический список. Следовательно, его применение оптимально в небольших сетях с устойчивыми именами NetBIOS и IP-адресами. Обеспечивать актуальность данных файла LMHOSTS в крупных или более динамических сетях может быть затруднительно, если вообще возможно.

3 Служба имен интернета для Windows (WINS)

Windows Internet Naming Service (WINS, служба имен Интернета для Windows) представляет собой NetBIOS Name Server (NBNS, сервер имен NetBIOS), определенный стандартами, опубликованными IETF в документах RFC 1001 и RFC 1002. Эти стандарты описывают использование сетей типа TCP/IP поверх NetBIOS, называемых для краткости NetBT. Серверные версии Windows NT и Windows 2000 включают WINS для регистрации имен NetBIOS компьютеров сети и разрешения этих имен в эквивалентные IP-адреса. Использование WINS позволяет значительно снизить широковещательный трафик сети и упростить администрирование Windows-сетей, включающих множество сегментов.

По существу, WINS -- это имитация службы DNS, выполненная в компании Microsoft и предназначенная для пространства имен NetBIOS.

Когда начались эксперименты Microsoft с совместным использованием ресурсов NetBIOS вне границ сети, стала очевидной необходимость в чем-то вроде сервера имен NetBIOS (NBINS). Такая служба была смоделирована на основе успешных DNS-серверов, применяемых в сетях TCP/IP, а ее официальная спецификация была зафиксирована в документах RFC 1001 и RFC 1002. Серверы имен для NetBIOS over TCP/IP должны соответствовать этим документам. Последней версией сервера имен NBNS от Microsoft является WINS.

Компания Microsoft продолжала прилагать усилия к улучшению функциональных возможностей WINS-сервера и его интеграции в другие компоненты сетевой схемы Windows, включая службу Active Directory и собственную реализацию службы DNS.

v Microsoft DNS (MS DNS) -- выполненная в компании Microsoft реализация стандарта DNS, содержащая расширения, которые позволяют серверам MS DNS запрашивать службу WINS для разрешения имен NetBIOS. Для обратного поиска в домене in.addr.arpa сервера MS DNS могут использовать WINS-R, возвращая имена NetBIOS, связанные с данным IP-адресом.

3.1 Как работает WINS

WINS -- это серверная служба, работающая в системах Windows NT Server и Windows 2000 Server. WINS-сервер регистрирует имена NetBIOS и IP-адреса, причем его настройки позволяют возвращать IP-адрес, связанный с именем ресурса (для обратного WINS (reverse WINS), или WINS-R), или имена NetBIOS, связанные с IP-адресом.

WINS-сервер хранит данные о соответствиях имен адресам в базе данных. Каждая запись ресурса в такой базе данных содержит имя NetBIOS и связанный с ним IP-адрес, а также значение времени жизни (TTL) и номер версии данной записи. Номер версии облегчает репликацию базы данных на другие WINS-серверы.

WINS-серверы не принимают участия в широковещательной регистрации и разрешении имен (по методу b-узла). Вместо этого они обмениваются однонаправленными сообщениями о регистрации и разрешении имен непосредственно с WINS-клиентами, относящимися к р-узлам, h-узлам и т-узлам. Кроме того, WINS-серверы могут взаимодействовать друг с другом, с WINS-агентами, а также с DHCP- и DNS-серверами Microsoft.

3.2 Различные конфигурации WINS

В зависимости от требований той или иной сети можно применять различные способы развертывания WINS-серверов. Функции WINS-сервера, DNS-сервера и контроллеры домена Active Directory могут быть реализованы как на одной, так и на нескольких физических машинах. Один WINS-сервер может обслуживать множество подсетей, однако зависимость от одного сервера означает наличие единой точки отказа. Кроме того, размещение WINS-сервера вне локальной сети приводит к появлению дополнительного WAN-трафика. По возможности вам следует завести хотя бы один вторичный WINS-сервер, т. к. это позволит избежать проблемы единой точки отказа.

Если подсети достаточно крупны, то оправданной может быть организация отдельных WINS-серверов для каждой из них. Возможность репликации, которой обладает WINS-сервер, позволяет сохранить текущие записи в распределенной среде, а присутствие локальных WINS-серверов снижает объемы WAN-трафика.

3.3 Интеграция WINS и DNS

Реализация DNS-сервера Microsoft (MS DNS) позволяет использовать службу WINS для разрешения имен NetBIOS в первичном домене или в корневом домене зоны. Служба MS DNS не может разрешать имена NetBIOS, не являющиеся прямыми потомками корня зоны или первичного DNS-домена. Например, имя frank.example.com является прямым потомком домена example.com; таким образом, DNS-сервер, обслуживающий этот первичный домен, может уверенно применять службу WINS для разрешения такого имени. Имя frank.accounting.example.com не является прямым потомком домена example.com; следовательно, DNS-серверы, обслуживающие первичный домен example.com, не могут разрешить его как имя NetBIOS. Это ограничение унаследовано от исходной схемы NetBIOS. Так как имя NetBIOS не содержит сетевого компонента, это -- всего лишь имя, но не адрес.

Если в сети присутствуют субдомены, то можно выбирать между двумя вариантами интеграции WINS и MS DNS. Если субдомены достаточно крупны, имеет смысл делегировать эти домены таким образом, чтобы у каждого из них были свои записи начала полномочий (Start of Authority, SOA) с собственными корневыми зонами службы DNS (рисунок 3.1). В каждом из них серверы MS DNS смогут разрешать имена NetBIOS средствами службы WINS, поскольку они будут обслуживать первичный домен.

Рисунок 3.1 - WINS серверы в корневой зоне DNS-доменов

Вместо этого вы можете создать специальный домен только для клиентов NetBIOS (рисунок 3.2). Не забывайте, что DNS-домен является логическим, а не физическим объектом. Ели все клиенты NetBIOS принадлежат к домену netbios.example.com, вы можете сделать его первичным. Это решение облегчает интеграцию в сетях, содержащих серверы Linux, UNIX и Microsoft DNS. Решив создать специальный домен для имен NetBIOS, вы должны будете добавить соответствующее доменное имя в списки суффиксного поиска DNS всех клиентов. Если домен NetBIOS присутствует в таком списке, клиент применяет этот домен для поиска ресурсов NetBIOS. Добавить запись в список суффиксного поиска DNS клиента можно как вручную (в TCP/IP Properties), так и с помощью DHCP.

Служба DNS никак не может узнать, например, что frank.example.com -- это имя NetBIOS, а не IP-имя. Так как это имя по форме соответствует IP-имени, сервер MS DNS сначала проверит адресные записи (А) домена example.com в своей базе данных. Нужные записи ему найти не удастся, и после этого он произведет поиск в кэше имен NetBIOS для этого домена; если и теперь ничего не получится, он свяжется с настроенным WINS-сервером (или с несколькими такими серверами). Если WINS-сервер ответит, сервер MS DNS кэширует этот ответ и передаст информацию процессу, подавшему исходный запрос на разрешение имени (Name Resolution Request).

Рисунок 3.2 - В этой сети создан специальный домен для WINS-разрешения

В ходе конфигурации сервера MS DNS вы можете указать ему один или несколько WINS-серверов, с помощью которых он будет выполнять разрешение имен NetBIOS. Это можно сделать во время исходной конфигурации, с помощью консоли DNS (DNS Console) или посредством прямого редактирования реестра. Имя WINS-сервера вводится в базу данных сервера MS DNS как запись ресурса (RR). Схема записи ресурса WINS выглядит примерно так:

owner class wins [LOCAL] L<значение>] [С<значение>] <wins_address>

Элементы в нижнем регистре -- это маркеры, в верхнем регистре -- константы. Элементы в угловых скобках -- это значения, а элементы в квадратных скобках необязательны. В базе данных никаких скобок не ставится. Элементы разделяются пробелами, и поэтому сами элементы пробелов содержать не могут. Описания каждого элемента следуют ниже.