Адресация в глобальных сетях

Основы IP-протокола

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

Адресация современного Интернета основана на про­токоле IP (Internet Protocol), история которого нераз­рывно связана с транспортным протоколом TCP.

Концепция протокола IP представляет сеть как мно­жество компьютеров (хостов), подключенных к некото­рой интерсети. Интерсеть, в свою очередь, рассматрива­ется как совокупность физических сетей, связанных маршрутизаторами. Физические объекты (хосты, мар­шрутизаторы, подсети) идентифицируются при помощи специальных IP-адресов. Каждый IP-адрес представля­ет собой 32-битовый идентификатор. Принято записы­вать IP-адреса в виде 4-х десятичных чисел, разделен­ных точками.

Для этого 32-х битовый IP-адрес разбивается на че­тыре группы по 8 бит (1 байт), после чего каждый байт двоичного слова преобразовывается в десятичное число по известным правилам. Например, IP-адрес:

10010011 10000111 00001110 11100101 преобразовывается указанным способом к следующему виду: 147.135.14.229.

 

Классы адресов вычислительных сетей

Каждый адрес является совокупностью двух иденти­фикаторов: сети — NetID, и хоста — HostID. Все воз­можные адреса разделены на 5 классов, схема которых приведена на рисунке 5.

Из рисунка 5 видно, что классы сетей определяют как возможное количество этих сетей, так и число хос­тов в них. Практически используются только первые три класса:

Класс А определен для сетей с числом хостов до 16777216. Под поле NetID отведено 7 бит, под поле HostID — 24 бита.

0 7 15 23 31

	Номер сети (8 бит)	Номер узла (24 бит)
		Номер сети (16 бит)	Номер узла (16 бит)
			Номер сети (24 бит)	Номер узла (8 бит)
				Адреса для многопунктовой адресации
					Резерв адресов

Класс В используется для среднемасштабных сетей (NetID — 14 бит, HostlD — 16 бит). В каждой такой сети может быть до 65 536 хостов.

Класс С применяется для небольших сетей (NetId — 21 бит, HostID — 8 бит) с числом хостов до 255.

 

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

Постоянное расширение сети Internet привело к де­фициту уникальных адресов для вновь подключаемых узлов. С другой стороны, система адресации в такой сети должна быть универсальной и удобной для пользовате­ля. Последнее обстоятельство особенно было важно с началом использования ресурсов сети не только специа­листами, но и неподготовленными пользователями, не владеющими тонкостями адресации в сети. Решающим аргументом для перехода к альтернативным способам ад­ресации в сети, удобным для работы пользователей, было неудобство запоминания 32-х битового кода, идентифи­цирующего отдельный узел. Это неудобство проявилось сразу же, когда сеть использовалась узким кругом специ­алистов. Поэтому появилась альтернативные формы за­писи 32-х битового IP-адреса — десятичная (195.224.11.77) и шестнадцатеричная (0xffffff80) дот-нотации. После­дняя форма записи особенно была удобной для програм­мистов, часто применяющих шестнадцатеричный алфа­вит для записи кода программы.

Впоследствии с появлением в сети различных серви­сов (электронная почта и другие службы), а также с увеличением числа узлов и такая форма записи оказа­лась неудобной, поскольку достаточно сложно запом­нить несколько цифровых адресов, даже в десятичной дот-нотации. Это обусловило появление в сети ARPANET принципиально нового способа адресации, заключаю­щегося в присвоении узлам сети доменного имени. В данном случае правильнее говорить о новом способе именования узлов сети, поскольку доменное имя не яв­ляется логическим адресом, например, как IP-адрес или физическим адресом, как, например, шестибайтовый адрес сетевого интерфейса. Доменное имя — это только лишь удобная для пользователя форма идентификации узла вычислительной сети (сервис).

Домен — группа узлов сети (хостов), объединенных общим именем, которое для удобства несет определен­ную смысловую нагрузку. Например, домен «ru» объе­диняет узлы на территории России, а домен «sport» — узлы, относящиеся к спортивным организациям или содержащие информацию о спорте и т. д.

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

Доменное имя — это уникальный алфавитно-циф­ровой идентификатор узла (состоит из символов ASCII-кода — букв от А до Z1 латинского алфавита и цифр от О до 9, также допускается дефис «—»).

Введение доменных имен поставило перед разработ­чиками задачу определения соответствия между домен­ным именем и логическим IP-адресом узла сети. Подоб­ная задача разработчиками ARPANET была решена, когда для определения соответствия между логическим IP-адресом и физическим адресом сетевого интерфейса в пределах локальной сети были введены протоколы ARP и RARP. Однако для глобальной сети решение такой задачи является более сложным.

Первоначально, когда ARPANET состояла из неболь­шого числа узлов, соответствие между доменными име­нами и IP-адресами узлов перечислялось в одном файле (hosts.txt) в виде таблицы соответствия цифрового ад­реса имени машины.

Авторство создания этих таблиц принадлежит Джо­ну Постелю. Именно он первым поддерживал файл hosts.txt, который можно было получить по FTP. Этот файл хранился в сетевом информационном центре Станфордского исследовательского института (SRI). Администраторы сетей передавали в SRI дополнения и изменения, происшедшие в конфигурации администрируемой ими сети. Периодически администраторы пере­писывали этот файл в свои системы.

В локальных сетях файлы hosts используются доста­точно успешно до сих пор. Практически все операцион­ные системы от различных версий Unix до Windows последних версий поддерживают эту систему соответ­ствия IP-адресов именам хостов.

Пользователь для обращения к узлу мог использо­вать как IP-адрес узла, так и его имя. Процедура ис­пользования имени заключается в следующем: сначала по имени в файле hosts находят IP-адрес, а затем по IP-адресу устанавливают соединение с удаленным инфор­мационным ресурсом.

С ростом сети ARPANET это стало чрезвычайно за­труднительно, поскольку файл увеличивался в разме­рах, а его пересылка по сети и хранение на каждом узле требовало значительных ресурсов. Однако главное неудобство заключалось в том, что такой способ не по­зволял оперативно учитывать все изменения в сети.

В 1984 году в сети ARPANET стала использоваться служба, получившая название системы доменных имен (Domain Name System — DNS). DNS была описана По­лом Мокапетрисом в двух документах: RFC-882 и RFC-883 (позже эти документы были заменены на RFC-1034 и RFC-1035).

В соответствии с RFC-1034 и RFC-1035, описываю­щими DNS, роль доменного имени в процессе установ­ки соединения осталась прежней. Это значит, что глав­ное, для чего используется DNS служба, — это получе­ние IP-адреса узла сети. Исходя из этого, любая реали­зация DNS является прикладным процессом, который работает над стеком протоколов межсетевого обмена TCP/IP. Таким образом, базовым элементом адресации в сетях TCP/IP с введением DNS остался IP-адрес, а доменное именование (система доменных имен) играет роль вспомогательного сервиса.

DNS состоит из трех основных частей:

■ пространство (множество) доменных имен (domain name space);

■ серверов доменных имен (domain name servers);

■ клиентов DNS (Resolver).

Пространство доменных имен имеет вид дерева (иерар­хии) узлов, как показано на рисунке 6 и подчиняется следующим правилам (RFC-1034):

■ имя корня — пустая строка, то есть полное имя обязательно завершается точкой1;

■ каждый узел дерева должен быть помечен про­стым именем, включающим допустимые символы;

■ прописные и строчные буквы в доменных именах не различаются;

■ допустимая длина простого имени не более 63 сим­волов;

■ доменные имена узлов в пределах одного домена должны быть уникальны;

■ допускается применение одинаковых доменных имен в разных доменах, как показано на рисунке 6, где доменное имя «.mil» используется для обо­значения домена первого уровня и домена второго уровня, являющегося поддоменом домена «.ru»;

■ полное имя узла образуется из последовательнос­ти имени самого узла и всех имен доменов, кото­рые с ним связаны (снизу вверх по соответствую­щей ветви дерева) до корня включительно, запи­сываемых слева направо и разделяемых точками, например, как показано на рисунке 6, узлу «.Ekfacultet» соответствует следующее полное до­менное имя «. Ekfacultet.urgi.rostov.ru»;

■ максимальная длина полного имени — 255 симво­лов, включая точки;

■ максимальное число уровней дерева — 1271;

■ кроме полного (абсолютного) имени узла (FQDN, fully qualified domain name) допускается примене­ние относительного (относительно некоторого опор­ного узла) имени, в этом случае завершающая точ­ка отсутствует;

■ поддерево доменных имен вместе со своим корне­вым узлом называется доменом (поддоменом), на­пример, обозначенная на рисунке 6 ветвь относит­ся к группе узлов («.Ekfacultet», «.Urfacultet», «.Phfaeultet», «.Dizfacultet», «.Reefacultet») и под-доменов («.rostov» «.urgi»), входящих в домен «.ru», а все узлы, показанные на рисунке 6 на самом нижнем уровне, входят в домен (поддомен) третьего уровня «.urgi» и т. д. ■ объединение узлов в домены является чисто логи­ческим, то есть не зависящим ни от месторасполо­жения, ни от IP-адреса, ни от способа маршрути­зации.

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

Корень — это множество все узлов Internet. Дан­ное множество подразделяется на домены первого или верхнего уровня (top-level или TLD).

Корневой зоной Internet и системой корневых серве­ров управляет ICANN, в частности, ICANN делегирует (передает) права управления зонами первого уровня gTLD (generic top-level domains, домены верхнего орга­низационного уровня) и ccTLD (country code top-level domains, национальные домены).

В соответствии с принятыми правилами право адми­нистрирования каждого домена первого уровня переда­ется одной конкретной организации (оператору регист­ра; администратором доменной зоны «ru» является Рос-НИИРОС). Зарегистрировать домен второго уровня, на­пример, в доменной зоне «ru» можно у одного из много­численных регистраторов (коммерческие организации, имеющие доступ к общей базе данных оператора регис­тра для данной доменной зоны).

Первоначально в ARPANET было семь доменов верх­него организационного уровня:

1. com (коммерческие организации);

2. edu (образовательные организации, в основном из США);

3. gov (правительственные организации США);

4. int (международные организации);

5. mil (военные организации США);

 

 

Рис. 6. Дерево доменных имен

6. net (организации, обеспечивающие сетевую инф­раструктуру);

7. org (некоммерческие организации).

В 90-х годах к ним были добавлены следующие до­мены:

8. aer o (организации, связанные с авиацией);

9. аrра (используется для отображения адресов в имена);

10. biz (коммерческие организации);

11. coop (кооперативы);

12. info (разное);

13. museum (музеи);

14. name (персональные домены);

15. pro (лицензированные профессионалы).

Список доменов ccTLD базируется на стандарте двух-ьуквенных кодов государств и территорий (ISO 3166).

Примеры доменов верхнего уровня ccTLD, соответ­ствующие отдельным государствам, приведены в табли­це 4.

В Internet система доменных имен реализована в виде распределенной базы данных, включающей в себя серверы DNS, клиенты DNS (resolver), объединенные об­щим протоколом запросов к базе данных и обмена ин­формацией между серверами.

Таблица 4

Примеры национальных доменов верхнего уровня

Страна	Код	Страна	Код
Аргентина	аг	Кипр	су
Армения	am	Киргизстан	kg
Австрия	at	Казахстан	kz
Азербайджан	az	Канада	са
Белорусь	by	Индия	id
Бельгия	be	Латвия	lv
Болгария	bg	Литва	It
Чехия	cz	Молдова	md
Эстония	ее	Нидерланды	nl
Финляндия	fi	Польша	Pi
Франция	fr	Португалия	Pt
Германия	de	Россия	ru
Греция	gr	Словакия	sk
Грузия	ge	Словения	si
Дания	dk	Испания	es
Венгрия	hu	Швеция	se
Италия	it	Швейцария	ch
Япония	JP	Узбекистан	uz
Украина	ua	Туркменистан	tm
Великобритания	gb	Соединенные Штаты	us

Информация, соответствующая каждому доменному имени, хранится в записях ресурсов RR (resource records) DNS-сервера. Основным типом хранимой информации является IP-адрес. Одному доменному имени может соответствовать несколько IP-адресов (в случае использо­вания нескольких сетевых интерфейсов на компьюте­ре). Кроме этого, в записях ресурсов может храниться дополнительная информация, например, максимально допустимое время кэширования1 полученной информа­ции (TTL, time to live).

В системе доменных имен различают несколько ти­пов DNS-серверов.

В зависимости от типа отклика на запрос серверы делятся на авторитетные (authoritative) и неавторитет­ные (поп authoritative).

Авторитетный отклик (authoritative response) воз­вращают серверы, которые являются ответственными за зону, в которой описана информация, необходимая клиенту DNS2.

Неавторитетный отклик (поп authoritative response) возвращают серверы, которые не отвечают за зону, со­держащую необходимую клиенту информацию.

В зависимости от способа поддержания базы данных авторитетные DNS-серверы делятся на первичные (primary) и дублирующие (secondary)3.

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

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

Администратор дублирующего сервера не изменяет данные описания доменной зоны, а только обеспечива­ет синхронизацию базы данных дублирующего сервера с базой данных первичного сервера.

Примером такой организации является система кор­невых (root-servers) DNS-серверов Internet. Всего в сети Internet 131 корневых DNS-серверов (таблица 5).

Корневые серверы являются основой всей системы доменных имен, поскольку являются авторитетными серверами для корневой зоны и содержат ссылки на такие же серверы зон первого уровня или сами являют­ся авторитетными серверами некоторых зон первого уровня (например, com. или net.).

На запрос о домене корневой сервер возвращает как минимум имя и адрес уполномоченного сервера домена первого уровня, в который входит указанный в запросе узел. Обратившись по полученному адресу, можно по­лучить имя и адрес уполномоченного сервера домена второго уровня и т. д.

Из всего списка корневых серверов только один из них (A.ROOT-SERVERS.NET) является первичным, а все остальные дублирующие, хотя они содержат иден­тичную информацию.

 

№	Обозначение	Доменное имя или организация ответственная за поддержание сервера	IP-адрес
1.	A.ROOT-SERVERS.NET	NS.INTERNIC.NET	198.41.0.4
2.	В.ROOT-SERVERS.NET	NS1.ISI.EDU	192.228.79.201
3.	CROOT-SERVERS.NET	CPSI.NET	192.33.4.12
4.	D.ROOT-SERVERS.NET	TERP.UMD.EDU	128.8.10.90
5,	E.ROOT-SERVERS.NET	NS.NASA.GOV	192.203.230.10
6.	F.ROOT-SER VERS.NET1	NS.ISC.ORG	192.5.5.241
7.	CROOT-SERVERS.NET	NS.NIC.DDN.MIL	192.112.36.4
8.	H.ROOT-SERVERS.NET	AOS.ARL.ARMY.MIL	128.63.2.53
9.	LROOT-SERVERS.NET	NIC.NORDU.NET	192.36.148.17
10.	J.ROOT-SERVERS.NET	VeriSign	192.58.128.30
11.	K.ROOT-SERVERS.NET	RIPENCC	193.0.14.129
12.	L.ROOT-SERV ERS.NET	ICANN	198.32.64.12
13.	М.ROOT-SERVERS.NET	WIDE	202.12.27.33

 

Благодаря такой организации в 2002 и 2003 годах с разницей в несколько месяцев Internet выдержал две глобальные атаки злоумышленников.

В первом случае осенью 2002 года массированная атака DoS (отказ в обслуживании), предпринятая про­тив 13 корневых DNS-серверов, нарушила работу вось­ми из тринадцати серверов. Соответственно, работоспо­собность сети сохранилась.

Во втором случае, в самом начале 2003 года (25 янва­ря), червь (вирус) SQL Slammer вызвал одну из круп­нейших и самых быстрораспространяющихся DoS атак. Примерно за 10 минут вирус распространился по всей сети и нарушил работу пяти из тринадцати корневых DNS-серверов.

Защита DNS-серверов любого уровня, а особенно кор­невых, является одной из проблем современной сети Internet.

DNS-клиенты обычно реализуются в виде набора под­программ1, используемых программами, которым требу­ется сервис доменных имен, например, Internet Explorer. В этом случае DNS-клиент обращается к указанному при настройке DNS-серверу (серверам), интерпретирует ответ и возвращает результат запросившей программе.

Обобщенная схема работы системы доменных имен иллюстрируется рисунком 7.

Пользователь инициирует запрос к web-серверу «www.urgi.ru». В соответствии с настройками сетевого подключения DNS-клиент формирует DNS-запрос к бли­жайшему DNS-серверу2 (как правило, по умолчанию DNS-сервер провайдера) об IP-адресе узла, на котором функционирует данный web-сервер.

Если DNS-сервер провайдера является авторитетным для доменной зоны «.ru», то он возвращает узлу пользо­вателя (а вернее программе, инициировавшей запрос) DNS-отклик, в котором содержится требуемый IP-адрес (в предположении, что такой web-сервер вообще зареги­стрирован).

В случае, если DNS-сервер провайдера не является авторитетным для доменной зоны «.ru», то он форми­рует аналогичный DNS-запрос к вышестоящему DNS-серверу (чаще всего, но не обязательно, корневому DNS-серверу). Корневой DNS-сервер в ответ на полученный запрос формирует DNS-отклик, в котором содержится IP-адрес авторитетного для данной доменной зоны DNS-сервера, получив который, DNS-сервер провайдера сфор­мирует к нему запрос и полученный отклик вернет кли­енту. При этом полученная информация будет занесена в кэш-память DNS-сервера провайдера. В случае повтор­ного запроса от пользователя IP-адреса web-сервера «www.urgi.ru», DNS-сервер провайдера сформирует от­клик, используя информацию из кэш-памяти1, и не бу­дет обращаться к вышестоящему DNS-серверу.

Запросы клиентов (или серверов) могут быть рекур­сивными или итеративными. Рекурсивный запрос под­разумевает, что запрашиваемый сервер должен самосто­ятельно пробежаться по всей системе серверов (вплоть до корневого) до получения конечного ответа (в том числе отрицательного) и вернуть его клиенту. При этом сам сервер может пользоваться итеративными или рекур­сивными запросами. Сервер может отказаться выпол­нять рекурсивные запросы «сторонних» клиентов. При итеративном запросе сервер делает только один шаг

поиска и возвращает ссылку на авторитетный сервер (или конечный ответ, если он сам является авторитет­ным для данного домена). Дальнейший поиск произво­дится самим клиентом.

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

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