коммуникациям, которые, обычно, не такие
скоростные, как локальная сеть.
Стандартная маска подсети для адреса
класса С следующая:
11111111 11111111 11111111 00000000 (255.255.255.0)
Цифра 0 в маске подсети означает, что
соответствующий разряд в IP-адресе является
hostid. Например, чтобы разбить сеть класса С
на четыре подсети необходимо применить маску
подсети
11111111 11111111 11111111 11000000 (255.255.255.192)
Для IP-адреса сети класса С
194.93.173.67 (11000010 1011101 10101101 01000011)
применение такой маски даёт netid:
11000010 1011101 10101101 0100000 (194.93.173.64)
и hostid:
000011 (3)
Маска подсети показывает, что hostid могут
находиться в диапазоне 000001 до 111110 (от 1 до 62)
и первые два разряда четвертого октета
могут иметь значения от 00 до 11.
Следовательно, наша сеть класса С 194.93.173 (254
адреса), с помощью маски подсети разбита на
четыре подсети с 62-мя адресами (248 адресов + 4
адреса пошло на netid + 2 специальных адреса).
Маршрутизация
Когда узел обнаруживает, что необходимо
послать пакет в другую подсеть, он посылает
его по адресу, который указывается при
конфигурировании, как стандартный шлюз (default
gateway) или по адресу другого доступного
маршрутизатора, если стандартный шлюз
недоступен. Шлюз - это старый термин для
маршрутизатора (router).
Маршрутизатор получив пакет сравнивает
netid, содержащийся в адресе получателя с
известными ему (в маршрутизаторе находится
статическая или динамическая таблица
маршрутов). В случае если такой netid ему
неизвестен, он отправляет пакет своему
стандартному шлюзу, который соответственно
пытается далее определить маршрут пакета.
При маршрутизации IP-адреса отправителя и
получателя не изменяются. Изменяются
только соответствующие аппаратные адреса.
Некоторые возможности сети TCP/IP
Стандартные возможности сети TCP/IP
включают в себя:
Mail (электронная почта)
File Transfer (средства передачи файлов)
Remote Login (удаленное подключение)
Remote Execution (удаленное исполнение
приложений)
Remote Printing (печать на удаленных принтерах).
Различные приложения AIX используют
протоколы TCP/IP, например такие как:
Network File System (NFS)
Network Information Services (NIS)
Network Computing System (NCS)
Distributed Computing Environment (DCE)
Xwindow и AIXwindows
Xstation Manager
AIX Netwiev/6000
Конфигурирование TCP/IP
Для конфигурирования TCP/IP требуется
следующая информация:
Каждый сетевой интерфейс должен иметь
уникальный адрес (TCP/IP address), имя узла (hostname) и
почти всегда маску подсети (subnet mask).
Каждый компьютер должен иметь доступ к
таблице имен для трансляции имен в адреса.
Она находится либо в файле /etc/hosts, либо в Domain
Name Server (DNS).
Для использования DNS вы должны знать имя
домена (Domain Name) и адрес сервера имен (Address of the
Name Server).
Для обмена данными с другими сетями вы
должны знать адрес стандартного шлюза (address
of the default gateway).
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
Обзор доменной службы имен DNS
Как работает DNS
В сетях TCP/IP компьютеры для общения между
собой используют IP-адреса. Однако то, что
удобно машинам, неудобно людям. Есть
спорное мнение, что сама человеческая
натура протестует против запоминания чисел
типа 192.168.1.34 (что не мешает нам запоминать
телефонные номера с кодом города и страны,
типа 380-564-40-06-24). К тому же IP-адреса совсем не
информативны. По IP-адресу невозможно понять,
что это: сервер, ПК, маршрутизатор или
сетевой принтер. Приятней работать с
осмысленными именами, такими как account-server.
Тем не менее сетевые устройства обращаются
друг к другу, используя IP-адрес, а не имена.
Решает эту проблему система именования
сетевых объектов, которая отвечает за
преобразование символьных имен в IP-адреса.
Система именования выполняет функции
телефонной книги, в которой каждому номеру
телефона поставлена в соответствие запись
о фамилии или названии фирмы. Системе
передается имя (например archie.univie.ac.at), а она
возвращает IP-адрес (140.78.3.8).
Системы именования сетевых объектов
делятся на "плоские" и иерархические (доменные).
В "стародавние времена", когда Internet еще
называлась ARPANET и Сеть состояла лишь из
многотерминальных компьютеров типа
мэйнфреймов (при этом их количество
оставалось относительно невелико), была
реализована система именования для
одноуровневого (плоского) пространства
имен. Ее также называют "плоской"
системой именования. Каждый компьютер имел
файл (обычно /etc/hosts) со списком IP-адресов
хостов и их символьные имена. При появлении
в Internet нового компьютера информация о нем
заносилась в файл hosts, затем этот файл
рассылался на все другие машины.
Недостатки
такой схемы начали проявляться довольно
быстро: с переходом от больших машин к
персональным и с ростом Internet. Трафик,
связанный с обновлением информации при
добавлении компьютеров в Internet, грозил
забить все линии связи. Кроме того, каждое
имя в сети должно быть уникальным, а сделать
это становится все труднее и труднее.
Поэтому к середине 80-х годов появилась
другая, более гибкая система именования -
система имен доменов (Domain Name System, DNS).
DNS реализует иерархическое пространство
имен. Единицей измерения является домен (территория,
область). Понятие домена DNS не надо путать с
доменом Windows NT или доменом NIS. Они не имеют
друг к другу никакого отношения.
В DNS вся сеть представляется в виде
единого иерархического дерева. На вершине
располагается корневой домен (обозначается
символом "."). Ниже находятся домены
первого уровня. Поскольку Internet развивался в
первую очередь в США и за счет американских
налогоплательщиков, это вызвало некоторый
крен при формировании доменов первого
уровня: Internet как бы оказался поделенным
между США и всем остальным миром.
Наиболее известные домены первого уровня:
com - коммерческие организации (главным
образом в США); edu - учебные заведения США; gov -
правительственные учреждения США; mil -
военные учреждения США; net - различные
сетевые агентства и Internet-провайдеры; int -
международные организации; org -
некоммерческие учреждения; код страны -
двухбуквенный код для обозначения
государства (ru - для России, ua - для Украины и
т.п.). Ниже доменов первого уровня
располагаются домены второго уровня и так
далее вплоть до хостов. Для доменов первого
уровня, обозначающих государства, доменами
второго уровня часто бывают города или
области (например, kiev - для Киева или dp -Днепропетровская
область), а доменами третьего уровня -
предприятия и организации.
Любой хост или домен в Internet однозначно
идентифицируется так называемым полным
доменным именем (Fully Qualified Domain Name, FQDN). Его
иногда еще называют абсолютным доменным
адресом. Домены в FQDN записываются справа
налево в порядке подчинения и разделяются
точками. Каждая отдельная составляющая FQDN
называется меткой (label). Длина метки не
должна превышать 63 символа, а полная длина
FQDN - 255 символов.
Допустимыми символами
являются буквы английского языка, цифры и
знак дефиса "-" (знак дефиса не может
стоять в начале или конце метки). Регистр
букв значения не имеет, т. е. company1.krcrme.dp.ua. и
COMPANY1.KRCRME.DP.UA. обозначают один и тот же домен.
Обратите внимание на конечную точку в
полном доменном имени. Она обозначает, во-первых,
корневой домен, и, во-вторых, что
используется абсолютная адресация.
Кроме абсолютной применяется и
относительная доменная адресация. Когда
два устройства находятся в одном и том же
домене, они могут обращаться друг к другу по
имени, не указывая полного доменного пути.
Так, host2 обращается к host1 двумя способами: по
полному доменному имени host1.company1.krcrme.dp.ua. по
относительному доменному адресу host1
В полном доменном имени конечную точку
можно не ставить, поскольку обычно программное
обеспечение TCP/IP подразумевает, что
составное доменное имя (т.е. когда
присутствует более двух меток) обозначает
FQDN. Таким образом, company1.krcrme.dp.ua. и company1.krcrme.dp.ua
суть одно и то же.
Домены находятся в иерархическом
подчинении друг другу, причем домены
являются узлами дерева доменов, а хосты -
листьями. Понятие домена достаточно емкое и
в то же время гибкое. Оно не ограничивается
какими-то физическими границами, например
границами IP-сети или сегмента Ethernet. Доменом
DNS может быть и страна, и предприятие, и
отдел банка. Один домен может включать как
множество сетей, так и только часть одной
сети или даже подсети.
Как уже отмечалось, основное назначение DNS
состоит в преобразовании имени хоста в его
IP-адрес. На самом деле DNS является системой,
не зависимой от протокола сетевого уровня,
т. е. она может быть реализована не только в
среде TCP/IP.
Однако функции DNS этим не ограничиваются.
DNS позволяет получить следующую информацию:
IP-адрес хоста;
доменное имя хоста по его IP-адресу;
псевдонимы хоста, тип центрального
процессора и операционной системы хоста;
сетевые протоколы, поддерживаемые хостом;
почтовый шлюз;
почтовый ящик:
почтовую группу;
IP-адрес и доменное имя сервера имен
доменов.
Существует и ряд других, реже
используемых параметров.
DNS представляет собой распределенную базу
данных, размещенную на множестве
компьютеров. Такие компьютеры называют серверами
имен (Name Server), или просто DNS-серверами.
Каждый сервер имен содержит лишь небольшую
часть информации всего дерева DNS (обычно
информацию только по одному домену), но
знает адреса DNS-серверов вышестоящих и
нижестоящих доменов.
Программное обеспечение, которое
общается с серверами имен, называют
клиентом DNS (Resolver DNS). Клиент DNS выполняет
роль посредника между сетевыми приложениями
и серверами имен. При этом он, как правило,
скрыт от пользовательских программ.
Сетевые приложения используют клиент DNS
чаще всего неявно, через функции стека TCP/IP.
Однако приложение nslookup позволяет
получить любую информацию из базы DNS. Клиент
DNS входит в состав программного обеспечения
TCP/IP. Но стек TCP/IP, по-мимо DNS, поддерживает и
"плоскую" систему именования (через
файл hosts). Это позволяет обеспечить
работоспособность сетевых устройств при
проблемах с DNS (например при отсутствии
связи с сервером имен). Клиент DNS может
функционировать как на отдельном
компьютере, так и на сервере имен.
Сервер имен на самом деле отвечает не за
домен, а за так называемую зону управления
(Zone of Authority), в которую могут входить
несколько смежных доменов. Более того,
сервер имен способен управлять несколькими,
причем не обязательно смежными, зонами
одновременно.
Сервер имен содержит полную информацию по
своим зонам управления и хранит адреса
серверов зон вышестоящих и нижестоящих
доменов. Клиенты DNS и серверы имен кэшируют
в оперативной памяти данные, полученные от
других серверов имен.
Время, в течение которого информация
хранится в кэше, определяется источником
информации и обычно составляет от десятков
минут до нескольких суток.
Кэширование позволяет уменьшить трафик в
сети, а также снизить нагрузку на серверы
имен.
Серверы имен бывают нескольких типов. Первичный
сервер имен (Primary Name Server) хранит на своих
дисках главные файлы (master files), в которых
содержится вся информация о зонах
управления данного сервера. Эти файлы
загружаются в память сервера имен при его
запуске.
Вторичный сервер имен (Secondary Name Server)
используется как дубликат первичного
сервера, что обеспечивает
отказоустойчивость DNS. Он загружает
информацию с первичного сервера и затем
периодически ее обновляет, посылая
первичному серверу запросы.
Серверы "только для кэширования" (Cache-Only
Server) записывают в кэш информацию,
полученную от других серверов имен. Чаще
всего они используются в больших сетях для
разгрузки первичного сервера.
Это, однако, еще не все типы серверов имен,
но оставшиеся (серверы Forwarder и Slave Forwarder)
имеют лишь незначительные отличия в
обработке информации DNS.
По правилам Internet, для повышения
отказоустойчивости DNS зоной должны
управлять как минимум два сервера имен.
Обычно для этого устанавливают один
первичный и один-два вторичных сервера. При
добавлении компьютера в сеть или изменении
его IP-адреса, файлы (master files) редактируются
только на первичном сервере имен.
Обновление содержимого других серверов
имен данной зоны будет происходить по мере
устаревания содержимого их кэш-памяти. Эти
серверы сами должны посылать запрос
первичному серверу на обновление
информации по зоне.
Серверам имен других зон передается
только конкретная информация (а не данные
по всей зоне) и только по их запросам.
Таким путем удалось резко снизить в Internet
трафик, связанный с преобразованием имен в
IP-адреса.
Серверы имен могут работать в двух
режимах: нерекурсивном и рекурсивном.
Наиболее распространенным является
нерекурсивный режим. Сервер имен получает
запрос от клиента DNS, допустим, на
преобразование доменного имени в IP-адрес.
Если доменное имя входит в зону управления
сервера, то сервер возвращает ответ клиенту.
Ответ может быть положительным (т.е. IP-адрес)
или отрицательным (к примеру такого имени
нет). Если искомая информация не относится к
зоне управления данного сервера, но
присутствует в кэше сервера, то сервер имен
также посылает клиенту ответ с указанием
адреса сервера имен, который является
управляющим для этой информации. Если же
информация не присутствует в кэше, то
клиенту DNS отсылается IP-адрес сервера имен,
который ближе к нужному домену и который
может обладать необходимой информацией. В
этом случае клиент DNS посылает запрос по
данному адресу следующему серверу,
работающему аналогично описанному. Так
продолжается до тех пор, пока клиент не
доберется до нужного сервера имен,
располагающего требуемой информацией.
Таким образом, в нерекурсивном режиме
клиент сам осуществляет все запросы к
серверам имен.
При рекурсивном режиме работы клиент DNS
посылает запрос серверу имен, после чего
последний, при отсутствии нужной
информации, сам обращается по цепочке к
другим серверам имен. После получения
информации сервер имен отсылает клиенту
результат. Благодаря этому клиент DNS
освобождается от большей части работы по
поиску информации в DNS.
Чтобы работать в рекурсивном режиме,
сервер и клиент должны быть настроены
соответствующим образом. Однако в
большинстве случаев пользователь не имеет
возможности менять настройку режима работы
клиента, поскольку она "зашита" в
программное обеспечение TCP/IP.
Рекурсивный режим применяется реже
нерекурсивного, так как нагрузка на серверы
имен в этом случае значительно возрастает.
Да и для клиента такой режим не оптимален,
ибо в случае задержки ответа ему трудно
определить, что произошло: сбой на линии или
просто опрашивается очень длинная цепочка
серверов имен.
Сервисы DNS в AIX
Все сервисы доменного именования
полностью реализованы в AIX. Поддерживаются
следующие типы серверов имен:
1. Первичный сервер имен;
2. Вторичный сервер имен;
3. Сервер "только для кэширования";
4. Сервер Forwarder;
5. Удаленный сервер.
Клиент DNS в AIX, gethostbyaddr() и gethostbyname(), пытается
определить имена ис-пользуя следующую
процедуру:
Если файл /etc/resolv.conf не существует, клиент
DNS считает, что в сети используется плоская
система именования. Тогда он использует для
определения имен файл /etc/hosts.
В обратном случае, клиент DNS считает
локальную сеть доменной сетью и пытается
использовать для определения имени
нижеследующие источники в показанном ниже
порядке:
1. Сервер DNS;
2. Локальный файл /etc/hosts.
Функции сервера имен в AIX выполняет демон named.
Он контролируется посредством AIX SRC (system
resource control). Этот демон может стартовать
автоматически при каждом перезапуске
системы используя команду smit stnamed или если
будет отредактирован файл rc.tcpip убрав
комментарий в сроке #start /etc/named "$src_running"
Демон named стартует также при команде startsrc -s
named.
Хост AIX конфигурируется для использования
сервера имен используя следующие шаги:
1. Создайте файл /etc/resolv.conf включив в него
имя домена и адреса до 16-ти серверов имен.
Например:
domain komtek.dp.ua
nameserver 192.168.1.65
nameserver 192.168.1.194
Порядок записей серверов имен имеет
значение для определения порядка вызова
серверов: сначала самый первый сервер имен
из списка, далее второй и т. д.
Обычно первым указывают ближайший
вторичный сервер имен данного домена, а
затем - первичный. Это позволяет снизить
нагрузку на первичный сервер.
Если указанный первым в списке серверов
имен не работает, то пройдет заметный
промежуток времени (до нескольких секунд),
прежде чем клиент DNS обратится ко второму
серверу.
2. Создайте файл /etc/named.boot для определения
имени и типа локального демона named.
3. Создайте файлы /etc/named.* для определения
требуемых для демона данных. Формат этих
файлов должен соответствовать формата
записей стандартных ресурсов (Standard Resource Record
Format).
Демон named в AIX также поддерживает записи
ресурсов для почты типа MB (mailbox domain name), MR (mail
rename domain name), MG (mail group member), MINFO (mailbox or mail list
information) и MX (mail exchange).
Приложения пользователя AIX/6000 включает в
себя программы host и nslookup. В AIX/6000
также можно воспользоваться программой dig
для запросов к серверам имен.
Настройка клиентской части
Как уже было отмечено, программное
обеспечение TCP/IP одновременно поддерживает
и клиента DNS, и файл hosts. Содержимое файла /etc/resolv.conf
мы рассмотрели уже выше. Файл hosts отвечает
за "плоскую" систему именования.
Местонахождение этого файла зависит от
операционной системы (AIX - /etc/hosts, DOS и Windows -
ETC\HOSTS, NetWare - SYS:\ETC\HOSTS).
Формат его очень прост: он состоит из
строк, каждая из которых определяет один
хост: <IP-адрес> <имя> [<псевдоним> ...
<псевдоним>]
Например:
192.168.1.67 granat devil
192.168.1.80 www.komtek.dp.ua
192.168.1.37 alpha
Обратите внимание, что файл hosts может
содержать имена в доменном формате.
Настройка сервера имен
Среди администраторов сетей бытует
мнение, что DNS следует использовать только
при наличии подключения к Internet. Но DNS
позволяет упростить администрирование
локальных сетей TCP/IP независимо от того,
имеют они выход в Internet или нет. При
отсутствии DNS добавление компьютера в
локальную сеть приводит к тому, что в файл
hosts каждого хоста необходимо ввести
информацию о новом компьютере. Это нетрудно,
если машин в сети немного. А если их десятки
или сотни? При использовании DNS вся
процедура сводится к добавлению одной-двух
строк в файлы базы DNS на первичном сервере
имен. После этого хосты сети будут
распознавать новый компьютер по имени
автоматически. Если по каким-либо причинам
необходимо изменить IP-адрес или имя хоста,
то с DNS сделать это довольно просто. Кроме
того, использование DNS значительно
облегчает процедуру подключения
корпоративной сети к Internet.
Стандарты DNS
Настройка базы DNS задается в специальных
текстовых файлах на серверах имен. Форматы
записей в этих файлах регламентируются
стандартами, изложенными в документах RFC (Request
For Comments). Они разрабатываются "законодательным"
органом Internet - IETF (Internet Engineering Task Force). Однако
сам набор файлов и порядок их загрузки на
серверах имен RFC не регламентируется. Для
этого существует стандарт de facto под
названием BIND (Berkley Internet Name Domain). Данная
спецификация была разработана в
университете Беркли и впервые реализована
в BSD Unix. Подавляющее большинство серверов
имен поддерживают спецификацию BIND.
Многие версии программного обеспечения
серверов имен имеют административные
утилиты, упрощающие настройку и управление
базами DNS. Тем не менее администраторы сетей,
как правило, предпочитают не пользоваться
ими, а работать напрямую с файлами базы DNS.
Хотя это несколько усложняет
администрирование, но в то же время дает
максимальную гибкость и полный контроль
при управлении DNS.
В общем случае порядок запуска серверов
имен следующий: сначала создаются файлы
базы DNS (напрямую или через
административные утилиты), а затем
запускается сервис DNS (в AIX - демон named).
Формат записей в файлах базы DNS
В файлах базы DNS серверов имен
используется так называемый формат записи
стандартных ресурсов (Standard Resource Record Format).
Выглядит этот формат следующим образом:
[<Name>] [<TTL>] [<Class>] <Type> <Data>
Каждая составляющая здесь является полем
записи и отделена от других пробелами или
знаками табуляции.
<Name> - имя описываемого ресурса. Оно
зависит от поля <Type> и может обозначать
домен, зону управления, имя хоста и т. д. Если
поле <Name> пустое, то в качестве него
используется последнее заданное поле <Name>
(в предыдущих записях).
<TTL> - время жизни (в секундах).
Определяет, как долго клиент DNS будет
хранить запись в кэш-памяти. Если данное
поле пустое, то в качестве <TTL> берется
значение поля <Minimum>, задаваемое в записи
SOA (см. ниже).
<Class> описание класса используемых
протоколов. Для Internet (TCP/IP) значение этого
поля - IN. Если поле пустое, то в качестве него
используется последний заданный класс.
<Type> - поле, задающее тип ресурса
записи. Возможные значения этого поля
приведены в разделе "Типы ресурсов".
<Data> - поле, устанавливающее данные
текущего ресурса. Его содержание зависит от
поля <Type>. Поле <Data> может быть
составным, т. е. состоять из нескольких
полей.
Следующие символы в записях имеют
специальное значение (ниже перечислены
некоторые из этих символов).
. Отдельно стоящая точка в поле <Name>
обозначает текущий домен.
@ Отдельно стоящий символ "@" в поле <Name>
обозначает текущий исходный домен.
( ) Скобки используются для размещения
поля <Data> на нескольких строках (когда
поле <Data> занимает несколько строк).
* Метасимвол. Заменяет любой набор
символов.
; Символ комментария. От этого символа и до
конца строки информация игнорируется.
Примечание. Следует знать, что в записях
ресурсов доменное имя, не заканчивающееся
точкой, считается относительным. При
обработке оно прибавляется к текущему домену.
Поэтому, когда задается полное имя, его
необходимо заканчивать точкой.
Типы ресурсов
Тип ресурса задается в поле <Type> записи
ресурса. Типов ресурсов множество. Полный
их список можно узнать в соответствующих RFC
(см. "Дополнительную информацию"). Ниже
приводятся наиболее используемые типы.
SOA Начало полномочий (управления)
сервера имен.
NS Сервер имен.
A Адрес хоста.
CNAME Каноническое имя. Используется для
задания псевдонимов.
HINFO Информация о хосте.
MX Почтовый шлюз.
PTR Указатель.
Рассмотрим каждый из этих типов.
SOA (начало полномочий)
Запись с ресурсом типа SOA обозначает
начало зоны управления сервера имен. Зона
управления действует до следующей записи SOA.
ПРИМЕР ЗАПИСИ SOA
<Name> [<TTL>] [<Class>] SOA <Origin> <Person> (
<Serial>
<Refresh>
<Retry>
<Expire>
<Minimum> )
komtek.dp.ua. IN SOA srv.komtek.dp.ua. root.srv.komtek.dp.ua. (
970308
3600
600
3600000
86400 )
Здесь поле <Data> является составным и
включает поля <Origin>, <Person>, <Serial> и т.
д.
<Name> Обозначает имя домена зоны
управления.
<Origin> Имя первичного сервера имен зоны.
<Person> Почтовый ящик лица,
ответственного за зону. Данное поле
формируется аналогично электронному
адресу, но вместо символа "@" ставится
точка (т. е. alex@komtek.dp.ua заменяется на
alex.komtek.dp.ua).
<Serial> Номер версии зоны. Когда
производятся изменения в зоне, то это число
необходимо увеличить. Именно по данному
полю ориентируется вторичный сервер имен,
определяя необходимость обновления
информации по зоне.
<Refresh> Время в секундах, по прошествии
которого вторичный сервер проверяет
необходимость обновления информации по
зоне.
<Retry> Время в секундах для повторного
обращения вторичного сервера зоны, если
ранее попытка обращения к первичному
серверу была неудачной.
<Expire> Предел времени в секундах. Если
вторичный сервер не может получить доступ к
первичному в течение этого времени, то он
будет считать информацию по зоне
устаревшей.
<Minimum> Значение TTL в записях ресурсов
данной зоны по умолчанию, т. е. когда поле <TTL>
пустое.
NS (сервер имен)
Запись с ресурсом типа NS обозначает имя
хоста, являющегося первичным сервером имен
для домена.
ПРИМЕР ЗАПИСИ NS
[<Domain>] [<TTL>] [<Class>] NS <Server>
komtek.dp.ua. NS srv1.komtek.dp.ua.
NS srv2.komtek.dp.ua.<Domain> обозначает домен, а <Server> - имя
сервера имен. В примере показывается, что
серверы srv1.komtek.dp.ua и srv2.komtek.dp.ua представляют