| Каталог документации / Раздел "Операционные системы, Разное" / Оглавление документа |
| |
|
В сетях 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.
Рекурсивный режим применяется реже нерекурсивного, так как нагрузка на серверы имен в этом случае значительно возрастает. Да и для клиента такой режим не оптимален, ибо в случае задержки ответа ему трудно определить, что произошло: сбой на линии или просто опрашивается очень длинная цепочка серверов имен.
Все сервисы доменного именования полностью реализованы в 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 задается в специальных текстовых файлах на серверах имен. Форматы записей в этих файлах регламентируются стандартами, изложенными в документах 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 серверов имен используется так называемый формат записи стандартных ресурсов (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
<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
[<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 представляют собой серверы имен домена komtek.dp.ua.
Запись с ресурсом типа A служит для задания сетевого адреса хоста. Здесь <Host> - доменное имя хоста, а <Address>- его IP-адрес.
ПРИМЕР ЗАПИСИ A
[<Host>]
[<TTL>] [<Class>] A
<Adress>
sri-nic.arpa.
A
10.0.0.51
Запись с ресурсом типа CNAME применяется для указания псевдонима хоста. <Nickname> обозначает псевдоним, а <Host> - официальное (каноническое) имя хоста.
ПРИМЕР ЗАПИСИ CNAME
[<Nickname>] [<TTL>] [<Class>] CNAME <Host>
rs1 CNAME srv1.komtek.dp.ua.
www CNAME srv2.komtek.dp.ua
ftp CNAME srv2.komtek.dp.ua
Запись с ресурсом типа HINFO служит для хранения информации о хосте, в частности об аппаратной платформе и операционной системе компьютера.
Поле <Host> обозначает доменное имя хоста, <Hardware> - аппаратную платформу, <Software> - ОС хоста. Значения полей <Hardware> и <Software> стандартизированы, их следует брать из RFC 1700.
ПРИМЕР ЗАПИСИ HINFO
[<Host>] [<TTL>] [<Class>] HINFO <Hardware> <Software>
pc1 HINFO IBM-PC MSDOS
rs1 HINFO IBM-RS/6000 AIX
Так как не на всех хостах запущен сервер e-mail, то для отдельных хостов или всего домена запись с ресурсом типа MX позволяет определить почтовый шлюз - компьютер, куда будет направляться электронная почта, предназначенная для этих хостов. Поле <Name> обозначает домен или имя хоста, для которого устанавливается почтовый шлюз. <Host> - имя хоста почтового шлюза. <Reference> задает приоритет доставки, при этом ноль означает самый высокий приоритет.
В примере показано, что если почта предназначена для домена komtek.dp.ua, то она доставляется на машину unix1.komtek.dp.ua. Если же почта предназначена для любого компьютера домена, имя которого оканчивается на -dos, то она направляется на unix2.komtek.dp.ua.
ПРИМЕР ЗАПИСИ MX
[<Name>] [<TTL>] [<Class>] MX <Preference> <Host>
komtek.dp.ua. MX 10 unix1.komtek.dp.ua.
*-dos.komtek.dp.ua. MX 10 unix2.komtek.dp.ua.
Таким образом, письмо, отправленное по адресу:
1. alex@komtek.dp.ua, переадресуется alex@unix1.komtek.dp.ua;
2. vad@pc-dos.komtek.dp.ua, переадресуется vad@unix2.komtek.dp.ua;
3. dba@host1.komtek.dp.ua, попадет к dba@host1.komtek.dp.ua.
Если администратор определяет несколько записей MX, то для указания порядка опроса почтовых шлюзов используется число (в примере - 10) первым опрашивается шлюз с меньшим числом.
Прежде чем рассматривать записи с ресурсом типа PTR, следует остановиться на поиске доменного имени хоста по его IP-адресу (так называемое обратное преобразование).
Структура имен в доменной системе построена так, что, продвигаясь вдоль иерархического дерева DNS, за счет последовательного обращения к серверам имен IP-адрес хоста можно найти по его имени (прямое преобразование). А вот доменное имя хоста по его IP-адресу в такой системе найти довольно трудно.
Для того чтобы облегчить эту задачу, в пределах общей доменной структуры был создан вспомогательный домен. Он имеет специальное название IN-ADDR.ARPA. Внутри этого домена существуют поддомены для каждой IP-сети. Имена этих поддоменов основаны на сетевых адресах, причем байты (октеты) IP-адресов представлены в обратном порядке.
Например, сеть cso.uiuc.edu имеет сетевой адрес 128.174 (вернее, 128.174.0.0, это IP-сеть класса B). Внутри этой сети имеется хост vmd.cso.uiuc.edu с IP-адресом 128.174.5.98. Тогда для всей сети вспомогательный домен будет 174.128.in-addr.arpa. Имя хоста в этом домене будет 98.5.174.128.in-addr.arpa.
Ресурсы с записью типа PTR служат для отображения этих специальных доменных имен в обычные. Поле <Special-name> обозначает специальное доменное имя (в домене IN-ADDR.ARPA), а поле <Name> - официальное доменное имя хоста.
ПРИМЕР ЗАПИСИ PTR ДЛЯ ХОСТА
[<Special-name>] [<TTL>] [<Class>] PTR <Name>
98.5.174.128.in-addr.arpa. PTR vmd.cso.uiuc.edu.
51.0.0.10.in-addr.arpa. PTR sri-nic.arpa.
Вспомогательный домен IN-ADDR.ARPA используется также для указания шлюза (маршрутизатора) для сетей. Шлюз представляет собой хост, соединяющий несколько IP-сетей. Для него существуют обычные записи PTR хоста, но, кроме того, имеются специальные записи PTR, представляющие IP-сети целиком. Эти записи включают только первые 1, 2 или 3 байта (октета) IP-адреса сети в зависимости от класса IP-сети (A, B или C).
Допустим, имеется шлюз gw.komtek.dp.ua, объединяющий сети класса A, B и C и имеющий соответствующие IP-адреса: 12.2.0.7, 129.14.1.3 и 194.140.13.2. Ниже представлены записи A и PTR для данного шлюза.
ПРИМЕР ЗАПИСЕЙ PTR И A ДЛЯ ШЛЮЗА
;Записи A gw.komtek.dp.ua. A 192.168.1.7 A 192.168.2.3 A 194.140.13.2 ; Записи PTR для шлюза 7.1.168.192.in-addr.arpa. PTR gw.komtek.dp.ua. 3.2.168.192.in-addr.arpa. PTR gw.komtek.dp.ua. 2.13.140.194.in-addr.arpa. PTR gw.komtek.dp.ua. ; Записи PTR для сетей 1.1.168.192.in-addr.arpa. PTR gw.komtek.dp.ua. 2.168.192.in-addr.arpa. PTR gw.komtek.dp.ua. 13.140.194.in-addr.arpa. PTR gw.komtek.dp.ua.
Как уже отмечалось, стандартом de facto в описании состава файлов DNS и порядка их загрузки на сервере имен является спецификация BIND. Она поддерживается во всех Unix-системах, в NetWare (программные продукты Novell NFS Services, FTP Services, NetWare/IP) и ряде других систем.
Согласно данной спецификации существует файл загрузки базы DNS. В Unix-системах обычно это файл /etc/named.boot, в NetWare - SYS:ETC\NAMED.CFG, который загру-жается при запуске сервиса DNS на сервере имен.
Основное назначение файла загрузки - указывать, где расположены файлы базы DNS, а также адреса серверов имен. При любом изменении как файла загрузки, так и файлов базы DNS сервис DNS необходимо перезапускать.
Файл загрузки базы DNS является текстовым и состоит из отдельных записей. Наиболее часто используются следующие записи:
1. directory <Path> Устанавливает каталог хранения файлов базы DNS, если не указаны абсолютные пути к файлам. Пример: directory /etc
2. domain <Domain> Определяет домен по умолчанию для данного сервера имен. Пример: domain komtek.dp.ua
3. primary <Domain> <FileName> Показывает, что сервер имен является первичным для домена <Domain> и что база домена хранится в файле <FileName>. Пример: primary komtek.dp.ua /usr/named.data
4. secondary <Domain> <IP-1> [<IP-2>...] <FileName> Указывает, что данный сервер имен является вторичным для домена <Domain>. Первичные серверы расположены по IP-адресам <IP-1>, <IP-2> и т. д. Данный вторичный сервер запрашивает по порядку первичные серверы и копирует полученную с первого ответившего первичного сервера информацию в файл <FileName>. Пример: secondary komtek.dp.ua 192.168.1.3 named.bak
5. cache <Domain> <FileName> Указывает, что данный сервер является кэш-сервером имен для домена <Domain>. Параметры кэш-сервера (прежде всего адреса и имена серверов имен корневого домена) считываются из файла <FileName>. Пример: cache . named.ca
6. Строка, начинающаяся с символа ";", считается комментарием. Кстати, для обозначения полного доменного имени в файле загрузки ставить точку в конце имени не обязательно: здесь все имена считаются полными.
Подводя итоги, рассмотрим пример настройки DNS на серверах имен типичной локальной сети TCP/IP. В примере принято, что локальная сеть подключена к Internet. В то же время показываются настройки, когда локальная сеть не имеет выхода в Internet. IP-адреса сетей и хостов, а также доменные имена вымышленные и приведены лишь для простоты понимания.
В реальной жизни, если сеть будет подключаться к Internet, необходимо получить официальные IP-адреса сетей и зарегистрированный домен. Их выдачей занимается специализированная организация в рамках Internet под названием InterNIC, при этом регистрация доменов происходит независимо от выдачи IP-адресов. Однако в России и Украине IP-адреса и домен можно получить с помощью своего Internet-провайдера. Доменное имя можно зарегистрировать через Internet-провайдера.
Если локальная сеть не имеет выхода в Internet, то IP-адреса и доменные имена можно выбрать по своему усмотрению. Если в дальнейшем возникнет потребность подключения к Internet, то перестроить DNS не составит труда.
Рассматриваемая локальная сеть состоит из двух IP-сетей класса C: 194.170.12.0 и 194.170.13.0. Допустим, эти сети образуют один домен komtek.dp.ua.
IP-сети объединяют шлюз (маршрутизатор) gw с адресами: 194.170.12.1 и 194.170.13.4. Подключение к Internet также происходит через данный шлюз.
В домене имеется первичный сервер имен srv1 (194.170.12.2) и вторичный сервер имен srv2 (194.170.13.3), а также ряд хостов: host1, host2, host3.
Хост mail (194.170.13.2) является почтовым шлюзом для всего домена, к тому же у него есть псевдоним host4.
Ниже представлены состав и содержимое базы DNS для первичного сервера имен srv1.komtek.dp.ua и для вторичного сервера srv2.komtek.dp.ua.
СОСТАВ И СОДЕРЖИМОЕ БАЗЫ DNS НА ПЕРВИЧНОМ СЕРВЕРЕ SRV1
; /etc/named.boot directory /etc domain komtek.dp.ua primary komtek.dp.ua named.data primary 12.170.194.in-addr.arpa named.rev1 primary 13.170.194.in-addr.arpa named.rev2 primary 0.0.127.in-addr.arpa named.local cache . named.ca ; /etc/named.data @ IN SOA srv1.komtek.dp.ua. root.mail.komtek.dp.ua. ( 970308 3600 600 3600000 86400 ) NS srv1.komtek.dp.ua. localhost A 127.0.0.1 gw A 194.170.12.1 A 194.170.13.4 HINFO IBM-RS/6000 AIX srv1 A 194.170.12.2 HINFO IBM-RS/6000 AIX host1 A 194.170.12.3 HINFO IBM-PC MSDOS host2 A 194.170.12.4 HINFO IBM-PC MSDOS host3 A 194.170.13.1 HINFO IBM-PC MSDOS mail A 194.170.13.2 HINFO IBM-PC UNIX host4 CNAME mail.komtek.dp.ua. srv2 A 194.170.13.3 HINFO IBM-PC UNIX komtek.dp.ua. MX 10 mail *.komtek.dp.ua. MX 0 mail.komtek.dp.ua. ; /etc/named.rev1 @ IN SOA srv1.komtek.dp.ua. root.mail.komtek.dp.ua. ( 960218 3600 600 3600000 86400 ) NS srv1.komtek.dp.ua. 1 PTR gw.komtek.dp.ua. 12.170.194.in-addr.arpa. PTR gw.komtek.dp.ua. 2 PTR srv1.komtek.dp.ua. 3 PTR host1.komtek.dp.ua. 4 PTR host2.komtek.dp.ua. ; /etc/named.rev2 @ IN SOA srv1. komtek.dp.ua.. root.mail. komtek.dp.ua. ( 970205 3600 600 3600000 86400 ) NS srv1.komtek.dp.ua. 1 PTR host3.komtek.dp.ua. 2 PTR mail.komtek.dp.ua. 3 PTR srv2.komtek.dp.ua. 4 PTR gw.komtek.dp.ua. 13.170.194.in-addr.arpa. PTR gw.komtek.dp.ua. ; /etc/named.local @ IN SOA srv1.komtek.dp.ua. root.mail.komtek.dp.ua. ( 960124 3600 600 3600000 86400 ) NS srv1.komtek.dp.ua. 1 PTR localhost ; /etc/named.ca . 999999 IN NS sri-nic.arpa. NS brl-aos.arpa. sri-nic.arpa. 999999 A 10.0.0.51 999999 A 26.0.0.73 brl-aos.arpa. 999999 A 192.5.25.82 999999 A 128.20.1.2
СОСТАВ И СОДЕРЖИМОЕ БАЗЫ DNS НА ВТОРИЧНОМ СЕРВЕРЕ SRV
; /etc/named.boot directory /etc domain komtek.dp.ua secondary komtek.dp.ua 194.170.12.2 named.data.bak secondary 12.170.194.in-addr.arpa 194.170.12.2 named.rev1.bak secondary 13.170.194.in-addr.arpa 194.170.12.2 named.rev2.bak primary 0.0.127.in-addr.arpa named.local ; выход в Internet cache . named.ca ; /etc/named.local @ IN SOA srv2.komtek.dp.ua. root.mail.komtek.dp.ua. ( 960124 3600 600 3600000 86400 ) NS srv2.komtek.dp.ua. 1 PTR localhost ; /etc/named.ca . 999999 IN NS sri-nic.arpa. NS brl-aos.arpa. sri-nic.arpa. 999999 A 10.0.0.51 999999 A 26.0.0.73 brl-aos.arpa. 999999 A 192.5.25.82 999999 A 128.20.1.2
Как для первичного, так и для вторичного сервера имен, в случае если локальная сеть не имеет выхода в Internet, следует убрать строку cache в файле /etc/named.boot и удалить файл /etc/named.ca.
Об именах и адресах серверов имен корневого домена, перечисленных в файле /etc/named.ca, необходимо справиться у Internet-провайдера. Кроме того, Internet-провайдер должен внести данные о серверах имен srv1.komtek.dp.ua и srv2.komtek.dp.ua в свою базу DNS, чтобы обеспечить доступ из Internet к машинам домена komtek.dp.ua.
Вспомогательный домен 0.0.127.in-addr.arpa, а также хост localhost (127.0.0.1) в каждой из зон необходимы для создания локальной "петли" TCP/IP.
Обратите внимание, что порядок записей в файлах базы DNS в общем случае значения не имеет, за исключением того, что запись SOA должна стоять первой в зоне управления.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |