Основные инструменты Internet

Так как Internet имеет различные уникальные ресурсы, то для их использования созданы разные инструменты, основными из которых являются:

1) электронная почта (е–mail) – где, в отличие от обычной почты, сообщения передаются практически моментально; при этом не имеет никакого значения, находится ли адресат за соседним столом или же в другом полушарии. По электронной почте можно передавать не только текст, но и компьютерные программы, графическое изображение, компьютерные игры и многое другое. Через электронную почту можно отправить факс – хотя и только текстовый.

2) списки рассылки (mailing lists) – подписавшись на такой список можно получать в свой электронный почтовый ящик информацию по интересующей теме.

3) электронные конференции (newsgroups, electronic conferences) – это своего рода «электронные доски объявлений» или «рабочие группы». От обычных конференций они отличаются тем, что их участники могут одновременно «присутствовать» сразу на нескольких конференциях, а если конференция международная, то нет необходимости приезжать на нее.

4) FTP – протокол передачи файлов, позволяет абонентам получать на свой персональный компьютер файлы с удаленных компьютеров (и отправлять, при необходимости, в ответ собственные файлы).

5) Telnet – протокол, позволяющий работать с ресурсами удаленного компьютера (в т.ч. выполнять различные программы, проверять на нем свою почту, получать доступ к базам данных и т.п.).

6) Gopher – инструмент для поиска и получения информации с помощью перемещения по системам вложенных меню.

7) WWW (World Wide Web) – средство работы с Internet, позволяющее легко добраться до нужного ресурса сети Internet. Это всемирная мультимедийная среда с мощнейшими средствами поиска и представления информации, в ней доступен и звук, и видео, и элементы виртуальной реальности.

8) On-line Databases – поиск данных в режиме диалога реального времени в различных базах данных, поддерживаемых на компьютерах Internet и многие другие.

Система доменных имен

Числовая адресация удобна для машинной обработки таблиц маршрутов, но совершенно не приемлема для использования ее человеком. Запомнить наборы цифр гораздо труднее, чем осмысленные имена. Для облегчения взаимодействия в сети Internet сначала использовались таблицы соответствия числовых адресов именам машин. Эти таблицы сохранились до сих пор и используются многими прикладными программами. Некоторое время даже существовало центральное хранилище соответствий, которое можно было по FTP скачать на свою машину из ftp.internic.net. Это файлы с именем hosts. Если речь идет о системе типа Unix, то этот файл расположен в директории /etc и имеет следующий вид (таблица 20.1).

Таблица 20.1 – Пример таблицы имен хостов (файл /etc/hosts)

IP–адрес	Имя машины	синонимы
127.0.0.1	Localhost	Localhost
144.206.160.32	Polyn	Polyn
144.206.160.40	Apollo	www

Последний столбец в этой таблице является необязательным. Пользователь для обращения к машине может использовать как IP–адрес машины, так и ее имя или синоним (alias). Обращения, приведенные ниже, приводят к одному и тому же результату – инициированию сеанса telnet с машиной Apollo:

telnet 144.206.160.40 или telnet Apollo или telnet www

В локальных сетях файлы hosts используются достаточно успешно до сих пор. Практически все операционные системы поддерживают эту систему соответствия IP–адресов доменным именам. Однако такой способ присвоения символьных имен был хорош до тех пор, пока Internet был небольшим. По мере роста сети стало затруднительным держать большие списки имен на каждом компьютере. Для того, что бы решить эту проблему, была придумана DNS (Domain Name System).

Принципы организации DNS

Любая DNS является прикладным процессом, который работает над стеком TCP/IP. Таким образом, базовым элементом адресации является IP–адрес, а доменная адресация выполняет роль сервиса. DNS – это информационный сервис Internet, и, следовательно, протоколы его реализующие относятся к протоколам прикладного уровня стандартной модели OSI. Система доменных адресов строится по иерархическому принципу. Однако иерархия эта не строгая, так как нет единого корня всех доменов Internet. Если более точно, то такой корень в модели DNS есть. Он так и называется «ROOT». Однако единого администрирования этого корня нет. Администрирование начинается с доменов верхнего, или первого, уровня. В 80–е годы были определены первые домены этого уровня и были рассчитаны на США:

· gov – государственные организации

· mil – военные учреждения

· edu – образовательные учреждения

· com – коммерческие организации

· net – сетевые организации

Позднее, когда сеть перешагнула национальные границы США, появились национальные домены типа:

· uk – Объединенное королевство

· jp – Япония

· au – Австралия

· ch – Чехия

· su – СССР

· ru – Россия и т.п.

Для СССР также был выделен домен su. После 1991 года, когда республики союза стали суверенными, многие из них получили свои собственные домены: ua, ru, 1а, Н, и т.п.

Вслед за доменами первого уровня следуют либо географические домены (kazan.ru, tatarstan.ru), либо организации (kstu.ru). В настоящее время практически любая организация или физическое лицо может получить свой собственный домен второго уровня. Далее идут домены третьего уровня, например:

Efir.kazan.ru ipm.kstu.ru

Систему доменной адресации можно представлена на рисунке 20.3.

Служба доменных имен работает как распределенная база, данные которой распределены по DNS–серверам. Сервис DNS строится по схеме «клиент-сервер», где в качестве клиентской части выступает процедура разрешения имен – resolver, а в качестве сервера DNS-сервер.

Рисунок 20.3 – Система доменоной адресации

Например, когда обращаются к серверу ipm.kstu.ru, браузер, используя resolver, поступает следующим образом (рисунок 20.4):

Рисунок 20.4 – Работа процедуры resolver

1. Ищет запись ipm.kstu.ru в файле hosts, если не находит, то,

2. Посылает запрос на известный DNS–кэширующий сервер (как правило, локальный), если на этом сервере запись не найдена, то,

3. Сервер DNS–кэширующий обращается к DNS–ROOT серверу с запросом адреса DNS сервера отвечающего за домен первого уровня ru, если получает адрес, то,

4. Сервер DNS–кэширующий обращается к DNS серверу, отвечающего за домен первого уровня ru, с запросом адреса DNS сервера отвечающего за домен второго уровня kstu.ru, если получает адрес, то,

5. Сервер DNS–кэширующий посылает запрос на DNS сервер, отвечающий за домен второго уровня kstu.ru, если получает адрес, то,

6. Сервер DNS–кэширующий кэширует адрес и передает клиенту.

7. Клиент обращается по IP адресу –195.208.44.20.

Первичный – сервер, содержащий полную информацию о зоне. Вторичный – сервер, содержащий копию полной информации о зоне, полученную с первичного сервера. Кэширующий – содержит записи которые уже были запрошены.

Регистрация доменных имен

Для того, чтобы получить доменный адрес надо отправить заявку в РосНИИРОС (www.ripn.net), который отвечает за делегирование поддоменов в пределах домена ru. В заявке указывается адрес компьютера–сервера доменных имен, почтовый адрес администратора сервера, адрес организации и ряд другой информации. Разберем эту заявку на примере Международной лаборатории VEGA.

domain: vega.ru

descr: International Agency VEGA

descr: Kurchatov sq. 1

descr: 115470 Moscow

descr: Russian Federation

admin–c: Pavel B Khramtsov

zone–c: Pavel B Khramtsov

tech–c: Pavel B Khramtsov

nserver: vega–gw.vega.ru

nserver: ns.relarn.ru

nserver: polyn.net.kiae.su

dom–net: 194.226.43.0

changed: [e-mail] 961018

source: RIPN

person: Pavel B Khramtsov

address: International Agency Vega

address: Kurchatov sq. 1

address: 115470 Moscow

address: Russian Federation

phone: [phone]

fax–no: [phone]

e–mail: [e-mail]

changed: [e-mail] 961018

source: RIPN

При заполнении этой заявки следует иметь в виду, что она будет обрабатываться роботом–автоматом. Этот автомат проверяет ее на наличие ошибок заполнения и противоречия с существующей базой данных делегированных доменов. Так как робот не терпит неточностей, то заполнять заявку следует аккуратно. Автомат обрабатывает заявку, выделяет в ней записи для базы данных регистрации доменов. Сами записи состоят из полей, которые идентифицируется в заявке именем поля, после которого ставится символ «:».

В строке описания поля «domain:» указывается имя домена, которое необходимо зарегистрировать. Регистрировать следует как «прямую» зону, так и «обратную.

В строке описания поля «descr:» указывают название и адрес организации, которая запрашивает домен. Так как на одной строке эта информация не может разместиться, то команд descr может быть несколько /26/.

В строке описания поля «admin–c:» указывается персона, которая осуществляет администрирование домена. Поле имеет обязательный формат: <имя> <первая буква отчества> <фамилия>. Таких строк может быть несколько, если лиц отвечающих за администрирование домена больше одного.

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

Поле «zone–c:» заполняется для той персоны, чей почтовый адрес указан в записи описания зоны. Формат этого поля идентичен формату команды admin–c.

Поле «tech–c:» указывается для технического администратора домена, к которому обращаются в случае экстренных ситуаций. Формат этого поля совпадает с форматом команды admin–c. Во всех полях (admin–c, zone–c и tech–c) имеет смысл указывать координаты одного и того же человека.

В строке описания поля «nserver:» указывают доменные имена серверов зоны. Как правило, таких строк в заявке бывает несколько. Первым указывается primary или главный сервер домена. В нашем случае это vega–gw.vega.ru. На этом сервере хранится база данных домена. Вторым указывается secondary или дублирующий сервер домена. В нашем случае это ns.relarn.ru. Дублирующие сервера призваны повысить надежность работы всей системы доменных имен, поэтому дублирующих серверов может быть несколько. Если существуют другие дублирующие сервера, то указываются и они (сервер polyn.net.kiae.su из нашей заявки также является дублирующим для домена vega.ru). При указании дублирующих серверов первым следует указывать тот, который наиболее надежно обслуживает запросы к домену. При выборе места размещения дублирующих серверов следует иметь в виду, что сначала проверяется возможность взаимодействия именно с этими серверами. Если хотя бы один из них не откликается на запросы автомата, то заявка отклоняется.

Поле «sub–dom:» описывает поддомены домена. В нашей заявке нет поля sub–net, т.к. в домене vega.ru нет поддоменов. Но если бы нам понадобилось изменять структуру домена, а именно, разбить его на зоны, то тогда следовало бы включить в заявку между строками nserver и строкой dom–net строку:

sub–net: zone1 zone2

В этом случае весь домен vega.ru разбит на два поддомена: zone1 и zone2. Например, машина quest из зоны zone1 будет иметь доменное имя quest.zone1.vega.ru, а машина query из зоны zone2 – query.zone2.vega.ru. Поддомены указываются в команде sub-dom через пробел.

Поле «dom–net:» указывает на список IP–сетей данного домена. В рассматриваемой заявке указана только одна сеть 194.226.43.0, но если у организации, которая заводит свой собственный домен, имеется в наличии несколько сетей, то эти сети можно указать в этом поле, разделяя их пробелами.

Поле «changed:» является обязательным и служит указателем на то лицо, которое последним вносило изменения в заявку. В качестве значения поля после символа «:» указывается почтовый адрес этого лица и, через пробел дата внесения изменения в формате ГГММДД (Г–год, М–месяц, Д–день).

Последняя запись в заявке – это поле «source», которое отделяет различные записи во входном потоке данных программы робота. Значение этого поля –RIPN.

Вслед за записью заявки следует запись описания персоны. Именно эта запись позволяет связывать поля admin–c, zone–c, tech–c с информацией о конкретном лице, которая содержится в записи описания персоны.

Запись описания персоны начинается с поля «person:». В данном поле указывается информация о лице (персоне). Обычно, данное поле имеет следующий формат: <имя> <первая буква отчества> <фамилия>.

Поле «address:» вслед за полем «person:». Данное поле состоит из нескольких строк, каждая из которых начинается с имени поля. Первым указывается организация, во второй строке – улица и номер дома, в третьей –почтовый индекс и название города или поселка, в последней строке – название страны. Одним словом – это типичный почтовый адрес.

За адресом следует поле «phone:». В нем указывается номер телефона, по которому можно связаться с указанным лицом. Номер задается с указанием номера страны и кода города. Для Москвы – +7 495 _________. Телефонов можно указать несколько.

Все выше сказанное для поля «phone:» относится и к полю «fax–no:». В этом поле указывается номер телефакса.

Поле адреса электронной почты – «e–mail:» не является обязательным полем заявки.

В поле «nic–hdl:» указывается персональный номер пользователя, если он у данного пользователя есть. Поле не является обязательным, но, как подчеркивается в инструкции по заполнению заявок «крайне желательно».

Последним полем в описании персоны, как и в заявке на домен, является поле «source:». В заявке можно указать несколько персон, что породит для каждой из них свою собственную запись в базе данных описания доменов. Информация о зоне и лицах, которые ответственны за ведение зоны (и не только о них) можно найти по команде:

/usr/paul>whois –h whois.ripn.net <имя зоны или персоны>

Теперь после описания самой заявки перейдем к описанию ее регистрации. После того как заявка отправлена, следует настроить и запустить сервер в локальном режиме. Администратор РосНИИРОС обычно извещает о том, что у администрации домена ru нет претензий к вашей заявке и разрешает запустить ваш сервер для тестирования.

Заявка отправляется на адрес [e-mail] и попадает на автомат обработки заявок, с которым бесполезно вступать в пререкания и прения по поводу различного рода ошибок и неточностей. Поэтому лучше всего сразу узнать телефон администратора и общаться с ним непосредственно.

При размещении сервера домена также следует позаботиться о том, чтобы существовало от 2–х до 4–х вторичных серверов на случай отказа основного сервера доменных имен.

В РосНИИРОС регистрируют не только «прямую» зону, но также и «обратную». Это две самостоятельные заявки. «Прямая» зона определяет соответствие доменного имени IP–адресу, в то время как «обратная» зона определяет обратное соответствие IP–адреса доменному имени.

Механизм поиска IP–адреса

Очень часто пользователи сообщают администратору системы, что та или иная машина системе не известна, хотя вчера с ней можно было работать. При этом, как правило, называют доменные имена компьютеров. Первое, что следует проверить в этой ситуации – реальную доступность к компьютеру по его IP–адресу, так как если по IP–адресу нельзя «достучаться» до удаленной машины, следует искать ошибки или отказы в работе сервиса доменных имен. Для этого используется программа named. Так как Resolver, собственно, не является какой–либо программой. Это набор процедур из системной библиотеки, которые позволяют прикладной программе, получать по доменному имени IP–адрес компьютера или по IP–адресу доменное имя. Сами эти процедуры обращаются к системной компоненте resolver, которая ведет диалог с сервером доменных имен и таким образом обслуживает запросы прикладных программ пользователя.

На запросы описанных выше функций в системах Unix отвечает программа named. Идея этой программы проста – обеспечить как разрешение, так называемых, «прямых» запросов, когда по имени ищут адрес, так и «обратных», когда по адресу ищут имя. Управляется named специальной базой данных, которая содержит соответствия между адресами и именами, а также адреса других серверов BIND (Berkeley Internet Name Domain), к которым данный сервер может обращаться в процессе поиска имени или адреса.

Опираясь на схему нерекурсивной процедуры разрешения имени, рассмотрим два способа разрешения запроса на получение IP–адреса по доменному имени.

Первый случай – запрос на получение IP–адреса в рамках зоны ответственности данного местного сервера имен:

1) Прикладная программа через resolver запрашивает IP–адрес по доменному имени у местного сервера.

2) Местный сервер сообщает прикладной программе IP–адрес запрошенного имени.

Несколько примеров, когда появляется запрос на получение IP–адреса по доменному имени. При входе в режиме удаленного терминала на компьютер polyn.net.kiae.su вводится команда:

/usr/paul>telnet polyn.net.kiae.su

/usr/paul>telnet polyn.net.kiae.su trying

144.206.130.137... login:

Строчка, в которой указан IP–адрес компьютера polyn.net.kiae.su, показывает, что к этому времени доменное имя было успешно разрешено сервером доменных имен и прикладная программа, в данном случае telnet получила на свой запрос IP–адрес. Таким образом, после ввода команды с консоли и до появления IP–адреса на экране монитора прикладная программа осуществила запрос к серверу доменных имен и получила ответ на него.

Это пример «прямомого» запроса. Но также существуют и «обратные» запросы. В «прямом» запросе прикладная программа запрашивает у сервера доменных имен IP–адрес, сообщая ему доменное имя. При «обратном» запросе прикладная программа запрашивает доменное имя, сообщая серверу доменных имен IP–адрес. Следует заметить, что скорость разрешения «прямых» и «обратных» запросов в общем случае разная. Все зависит от того, как описаны «прямые» и обратные «зоны» в базах данных серверов доменных имен, обслуживающих домен.

Рассмотрим теперь запрос прикладной программы к серверу доменных имен на получение IP–адреса по доменному имени из домена, который находится в ведении удаленного сервера доменных имен, т.е. сервера отличного от того, домену которого принадлежит компьютер, осуществляющий запрос.

В общем виде такая схема будет выглядеть следующим образом:

1) Прикладная программа обращается к местному серверу доменных имен за IP–адресом, сообщая ему доменное имя.

2) Сервер определяет, что адрес не входит в данный домен и обращается за адресом сервера запрашиваемого домена к корневому серверу доменных имен.

3) Корневой сервер доменных имен сообщает местному серверу доменных имен адрес сервера доменных имен требуемого домена.

4) Местный сервер доменных имен запрашивает удаленный сервер на предмет разрешения запроса своего клиента (прикладной программы)

5) Удаленный сервер сообщает IP–адрес местному серверу.

6) Местный сервер сообщает IP–адрес прикладной программе. Существует разница между доменом и зоной. Домен – это все множество машин, которые относятся к одному и тому же доменному имени. Однако сам домен разбивается на поддомены или, как их еще называют, зоны. У каждой зоны может быть свой собственный сервер доменных имен. Разбиение домена на зоны и организация сервера для каждой из зон называется делегирование прав управления зоной соответствующему серверу доменных имен, или просто делегированием зоны.

Кроме нерекурсивной процедуры разрешения имен возможна еще и рекурсивная процедура разрешения имен. Ее отличие от описанной выше нерекурсивной процедуры состоит в том, что удаленный сервер сам опрашивает свои серверы зон, а не сообщает их адреса местному серверу доменных имен. Рассмотрим эти два случая более подробно.