Протоколы DNS (структура, обработка запросов, ресурсные записи), ARP и RARP

Последние две строки в таблице 5.3 относятся только к запросам. Поле класс запроса позволяет использовать имена доменов для произвольных объектов (все официальные имена Интернет относятся к одному классу [IN] — 1). В сообщении DNS-сервера каждая из секций (дополнительной информации, ответов или узловых серверов имен) состоит из набора ресурсных записей, которые описывают имена доменов и некоторую другую информацию (например, их адреса). Появление ресурсных полей в DNS базе данных придают ей новые качества. Каждая запись описывает только одно имя, формат этих записей отображен на рис. 5.6.

Всего существует 20 различных типов RR-записей. Имя домена в такой записи может иметь произвольную длину. Поля тип и класс характеризуют тип и класс данных, включенных в запись (аналогичны используемым в запросах). Поле время жизни (TTL) содержит время (в секундах), в течение которого запись о ресурсах может храниться в буферной памяти (в кэше). Обычно это время соответствует двум дням. Формат информации о ресурсах зависит от кода в поле тип, так, для тип=1 — это 4 байта IP-адреса. Сервер имен может обслуживать и другие запросы, например, по IP-адресу определять символьное имя домена или преобразовать имя домена в адрес почтового сервера. Когда организация присоединяется к Интернет, она получает в свое распоряжение не только определенную DNSобласть, но и часть пространства в inaddr.arpa, соответствующую ее IP-адресам. Домен inaddr.arpa предназначен для определения имен по их IP-адресам. Такая схема исключает процесс перебора серверов при подобном преобразовании.

Имена в домене INADDR.ARPA могут иметь до четырех субполей помимо суффикса INADDR.ARPA. Каждое субполе представляет собой октет IP-адреса и содержит последовательность символов, отображающую коды в диапазоне 0-255. Так, имя для IP-адреса 192.148.166.137 (если оно существует) содержится в домене с именем 137.166.148.192.INADDR.ARPA. Запись адреса задом наперед диктуется общими принципами записи имен доменов (корневая часть имени находится справа). Направив в домен INADDR.ARPA несколько запросов относительно имен объектов с интересующими вас IP-адресами, можно получить следующий результат (таблица 5.3.1.), где в левой колонке записаны IP-адреса, имена которых разыскиваются, во второй записаны аппаратные адреса интерфейсов, через которые доступны искомые объекты. Поскольку первая и третья строки относятся к внешним по отношению к узлу ITEP объектам, здесь записан адрес интерфейса пограничного маршрутизатора. В третьей колонке содержится значение RTT в мсек, а в последней — имена объектов. IP-адресу 192.148.166.102 не соответствует никакого имени.

Задержка при выполнении команды telnet между выдачей команды и появлением на экране IP-адреса связана с доступом и работой DNSсервера. Пауза между появлением надписи Trying и Connected to определяется временем установления TCP-связи между клиентом и сервером. База данных имен может содержать и другую информацию. Типы такой информации представлены в таблице 5.3. Для извлечения информации из этой распределенной базы данных можно воспользоваться программой host (SUN или другая ЭВМ, работающая под UNIX). Рассмотрим несколько примеров (курсивом выделены команды, выданные с терминала).

host t cname cernvm.cern.ch
cernvm.cern.ch is a nickname for crnvma.cern.ch

Напомним, что CNAME — каноническое имя узла или ЭВМ, иногда называемое также псевдонимом (alias).

host t hinfo ns.itep.ru
ns.itep.ru HINFO SparcStation1 SunOS4.1.3

HINFO — информация об ЭВМ. Это обычно две последовательности символов, которые характеризуют ЭВМ и ее операционную систему. Много полезной информации можно узнать о почтовом сервере узла посредством команды:

host t mx cl.itep.ru
cl.itep.ru is a nickname for r02vax.itep.ru
r02vax.itep.ru mail is handled by relay1.kiae.su
r02vax.itep.ru mail is handled by relay2.kiae.su
r02vax.itep.ru mail is handled by mx.itep.ru
r02vax.itep.ru mail is handled by x4u2.desy.de
host v info.cern.ch
Trying domain "itep.ru"
rcode = 3 (Nonexistent domain), ancount=0
Trying null domain
rcode = 0 (Success), ancount=2
info.cern.ch   	86400	IN	CNAME	www.6.cern.ch
www6.cern.ch	86400	IN	A	128.141.202.119
Trying domain "itep.ru"
rcode = 3 (Nonexistent domain), ancount=0
Trying null domain
rcode = 0 (Success), ancount=1
The following answer is not authoritative:
www6.cern.ch	86400	IN	A	128.141.202.119
For authoritative answers, see:
CERN.CH		52256	IN	NS	dxmon.cern.ch
CERN.CH		52256	IN	NS	ns.eu.net
CERN.CH		52256	IN	NS	sunic.sunet.se
CERN.CH		52256	IN	NS	scsnms.switch.ch
Additional information:
dxmon.cern.ch 79157 IN A 192.65.185.10
ns.eu.net 56281 IN A 192.16.202.11
sunic.sunet.se 85087 IN A 192.36.125.2
sunic.sunet.se 85087 IN A 192.36.148.18
scsnms.switch.ch 72545 IN A 130.59.1.30
scsnms.switch.ch 72545 IN A 130.59.10.30

Опция -v, используемая совместно с командой host, позволяет получить более полную информацию об узле. Во второй колонке данной выдачи указано время жизни (TTL) в секундах. Значение TTL в первых строках соответствует суткам (24x60x60=86400). IN в следующей колонке указывает на принадлежность к классу Интернет. В четвертой колонке проставлены указатели типов запроса (см. табл. 5.3). В пятой колонке идут названия серверов имен и IP-адреса ЭВМ. Далее следуют коды предпочтения. MX-записи активно используются почтовыми серверами. Обмен MXзаписями производится в следующих случаях:

MX-записи снабжены 16-битными кодами предпочтения. Если для адреса имеется несколько MXзаписей, они используются в порядке нарастания этого кода. Если вы хотите узнать список доступных услуг на той или иной ЭВМ, вы можете выдать команду (WKS — Well Known Services, сюда не входят услуги прикладного уровня, например, услуги NEWSсервера и пр.):

host tv wks ns.itep.ru
ns.itep.ru WKS 193.124.224.35 udp domain tftp
ns.itep.ru WKS 193.124.224.35 tcp echo ftp telnet smtp time finger

Если вам нужно узнать IP-адреса того или иного узла, можно также воспользоваться командой host:

host vxdesy.desy.de
vxdesy.desy.de has address 131.169.35.78
vxdesy.desy.de has address 131.169.35.79
vxdesy.desy.de has address 131.169.35.76
vxdesy.desy.de has address 131.169.35.77

Большая часть данных относится к типу "А".

Выше уже говорилось, что для транспортировки DNSзапросов применяются протоколы UDP и TCP. Когда же следует использовать тот или иной протокол? Обычно применяется UDP. Когда в ответ на запрос программа получает отклик с битом флагов TC=1 (сообщение укорочено), программа повторяет запрос, но уже с использованием протокола TCP. Этот протокол применяется также для зонных обменов между первичным и вторичным DNSсерверами.

Обычно реализация сервера имен (версия BIND — Berkeley Internet Name Domain) предполагает наличие трех конфигурационных файлов:

named.boot — файл начальной загрузки сервера имен;

named.local — стартовый файл клиента DNS;

named.ca — исходный буфер имен и адресов.

Эти текстовые файлы, строки и фрагменты, начинающиеся с точки с запятой, представляют собой комментарии. В первом из перечисленных файлов строка, начинающаяся со слова sortlist, указывает на порядок присылки адресов при условии, что отклик на запрос содержит несколько адресов. Строка, начинающаяся со слова directory, содержит название каталога, где хранятся конфигурационные файлы (по умолчанию /etc). Строка cache сообщает имя файла­буфера имен и адресов (по умолчанию named.ca). Далее обычно следует несколько строк, начинающихся со слова primary. Эти строки указывают имена файлов (например, named.hosts или named.local), где содержится информация о соответствии имен и адресов для определенных субдоменов. Вместо имени файла может быть указан IP-адрес. Укладка данных в файле соответствует требованиям документа RFC-1033. Для вторичного (secondary) DNS файл named.boot имеет схожую структуру. Вместо строк со словом primary в этом файле присутствуют строки secondary. Эти строки содержат, помимо имен субдоменов и файлов, IP-адрес первичного DNS. Последний выполняет и функцию переадресации запросов вышестоящим серверам. Вторичный DNSсервер при невозможности выполнить запрос переадресует его первичному серверу, а не вышестоящему. Первичный сервер может создавать большой кэш­буфер для локального обслуживания часто поступающих запросов.

Файл named.local служит для спецификации интерфейса сервера имен и содержит в себе запись SOA (Start of Authority) и две ресурсных записи. Запись SOA определяет начало зоны. Символ @ в начале первой строки файла определяет имя зоны. Здесь же указываются опционные параметры:

Запись может выглядеть как (RFC-1033):

@ IN SOA SRINIC.ARPA. HOSTMASTER.SRINIC.ARPA. (
45 ;serial
3600 ;refresh
600 ;retry
3600000 ;expire
86400 ) ;minimum

В файле приводится имя первичного сервера имен для данного субдомена (флаг NS) и имя администратора с указанием адреса его электронной почты. Последняя запись в файле содержит указатель на местную ЭВМ. Первая цифра в строке этой записи содержит суффикс IP-адреса этой машины.

Файл named.ca используется для заполнения кэша при первичной загрузке DNS. Примером, иллюстрирующим возможное содержимое файла, можно считать следующую запись (взято из RFC-1033):

;list of possible root servers
. 1 IN NS SRINIC.ARPA.
NS C.ISI.EDU.
NS BRLAOS.ARPA.
NS C.ISI.EDU.
;and their addresses
SRINIC.ARPA. A 10.0.0.51
A 26.0.0.73
C.ISI.EDU. A 10.0.0.52
BRLAOS.ARPA. A 192.5.25.82
A 192.5.22.82
A 128.20.1.2
A.ISI.EDU. A 26.3.0.103

Первое поле представляет собой имя домена или субдомена, второе поле — значение TTL, третье — поле класс (Internet), четвертое — тип записи (NS для сервера имен или A для адреса), и последнее поле характеризует имя ЭВМ или IP-адрес. Если какие­то поля пусты, это означает, что они тождественны приведенным выше. Точка в начале первой строки указывает на корневой домен.

Для администраторов, обслуживающих DNS, весьма полезно ознакомиться с документом RFC-1536 ("Common DNS Implementation Errors and Suggested Fixes"). Ошибки при конфигурации DNSсервера могут привести к досадным ошибкам и отказам системы. Обычно при получении запроса DNS сначала определяется его зона и просматривается кэш. Если запрос не может быть выполнен, просматривается список вышестоящих DNSсерверов, которые могут содержать необходимую информацию, и запрос пересылается одному из них. Если клиент прислал рекурсивный запрос и сервер поддерживает рекурсию, запрос пересылается соответствующим серверам. Если рекурсия не поддерживается, сервер возвращает клиенту список DNS-серверов, предоставляя ему решать свои проблемы самостоятельно. Однако в некоторых случаях DNSсервер по ошибке может включить себя в такой список серверов. Если программное обеспечение клиента не проверяет список, запрос может быть послан этому серверу повторно, что вызовет бесконечный цикл запросов.

Возможна и другая схема возникновения циклов запросов. Предположим, что сервер <1> содержит в своем списке внешних DNS сервер <2>, а последний в свою очередь содержит в своем списке сервер <1>. Такого рода перекрестные ссылки трудно обнаружить, особенно если в перечне фигурирует большое число серверов. Иногда возникает ситуация, когда клиент, получив список DNSсерверов, не знает, что с ним делать, и посылает запрос повторно тому же серверу. Идентифицировать такого рода ошибки весьма трудно, особенно когда в это вовлечены внешние серверы, содержимое конфигурационных файлов которых недоступно.

Иногда DNS-сервер в ответ на запрос не присылает сообщений об ошибке и каких­либо данных клиенту. Это случается, когда запрашиваемое имя вполне корректно, но записей нужного типа не найдено. Например, запрошен адрес почтового сервера домена xxx.com. Домен этот существует, но рекорда типа MX не обнаружено. Дальнейшие события зависят от характера программного обеспечения клиента. Если клиент считает такого рода "отклик" некорректным, он может послать запрос повторно и т.д., и т.д. По этой причине в случае, если программное обеспечение это позволяет, рекомендуется ограничить число повторных запросов клиента. Приведенные примеры показывают, насколько актуальна корректная конфигурация DNS клиента и сервера.

В последнее время разработано несколько модификаций протокола DNS, направленных на совершенствование его безопасности (смотри, например, RFC-2535). В документе RFC-2537 рассмотрена возможность использования DNS для хранения ключей шифрования.

В системах Windows часто применяется своя служба имен WINS (Windows Internet Naming Service, см. RFC-2136 и RFC-2137). Эта служба совместима с системой динамического конфигурирования сети DHCP (Dynamic Host Configuration Protocol, использует динамическое распределение IP-адресов). В WINS, так же, как и в DHCP, имеются части, работающие у клиента и на сервере. WINS автоматически устанавливается и конфигурируется при установке системы DHCP. Эта система имеет удобную встроенную диагностику, позволяющую контролировать процесс обработки запросов к службе имен. WINS осуществляет преобразование NETBIOS-имен в IP-адреса. Эта техника предполагает применение протокола NetBIOS поверх TCP/IP (NetBT). В ОС WINDOWS 2000 технология WINS заменена DDNS (Dynamic Domain Name Service).

WINS-запросы обычно транспортируются в UDP-дейтограммах. При этом используется порт отправителя=137. В поле данных размешается 2октетное поле идентификатора, позволяющего связать запрос с откликом. Далее следует 2 байта флагов, в случае запроса туда записывается 0. За ним размещается два октета, содержащие число вопросов, 2 октета числа ответов и еще 4 нулевых октетов. Завершается кадр запроса двумя октетами поля типа ( 00 21 -> статус узла NetBIOS ) и полем класса (для Интернет 00 01 -> (IN,1) ). Такие запросы позволяют получить дополнительные данные (имя узла, его MAC-адрес, NetBIOS-имя, имя группы) об ЭВМ с заданным IP-адресом. Причем эта ЭВМ может находиться где угодно в Интернет, но непременно работать c OS Windows. Формат поля данных UDP-дейтограммы запроса показан на рис. 5.7.

В поле данных UDP-дейтограммы отклика располагается 2-байтовое поле идентификатора, идентичного содержащемуся в пакете запроса. Далее следует поле флагов с длиной в два октета. Формат поля данных UDP-дейтограммы отклика показан на рис. 5.8.

Поле флаги имеет следующую структуру (таблица 5.3.2.).

Для поля флаги имени характерна следующая структура (таблица 5.3.3).

Для поля флагов имени группы характерно следующее назначение бит (таблица 5.3.4.).

В последнее время развивается технология DDNS — динамического обновления ресурсных записей зоны DNS внешними ЭВМ или процессами (Dynamic DNS; RFC-2136). Клиенты с возможностями DDNS могут сами обновлять записи локальных серверов имен. Еще более интересное решение базируется на интеграции служб DHCP и DNS. В этом варианте серверы DHCP, поддерживающие DDNS, посылают соответствующему серверу DNS данные для обновления записей, включая имена NetBIOS клиентов DHCP. Запись обновляется после выделения IP-адреса. При реализации DDNS возникают проблемы безопасности. Часть этих проблем может быть решена путем использования цифровых подписей (RFC-2137).

Еще одной проблемой, связанной со службой имен, являются атаки, которые сопряжены с имитацией DNS. Для преодоления таких атак разработан метод транзакционных подписей TSIG (Transaction SIGnature).

5.1. Протокол преобразования адресов ARP

Любое устройство, подключенное к локальной сети (Ethernet, FDDI и т.д.), имеет уникальный физический сетевой адрес, заданный аппаратным образом. 6байтовый Ethernet-адрес выбирает изготовитель сетевого интерфейсного оборудования из выделенного для него по лицензии адресного пространства. Если у машины меняется сетевой адаптер, то меняется и ее Ethernet-адрес.

4-байтовый IP-адрес задает менеджер сети с учетом положения машины в сети Интернет. Если машина перемещается в другую часть сети Интернет, то ее IP-адрес должен быть изменен. Преобразование IP-адресов в сетевые выполняется с помощью ARP-таблицы. Каждая машина сети имеет отдельную ARP-таблицу для каждого своего сетевого адаптера. Нетрудно видеть, что существует проблема отображения физического адреса (6 байт для Ethernet) в пространство сетевых IP-адресов (4 байта) и наоборот.

Протокол ARP (address resolution protocol, RFC-826) решает именно эту проблему — преобразует IP в Ethernetадреса.

Рассмотрим процедуру преобразования адресов при отправлении сообщения. Пусть прикладная программа одной ЭВМ отправляет сообщение другой. Прикладной программе IP-адрес места назначения обычно известен. Для определения Ethernet-адреса просматривается ARP-таблица. Если для требуемого IP-адреса в ней присутствует Ethernet-адрес, то формируется и посылается соответствующий пакет. Если же с помощью ARP-таблицы не удается преобразовать адрес, то выполняется следующее:

Каждая машина, принявшая ARP-запрос, в своем ARP-модуле сравнивает собственный IP-адрес с IP-адресом в запросе. Если IP-адрес совпал, то прямо по Ethernet-адресу отправителя запроса посылается ответ, содержащий как IP-адрес ответившей машины, так и ее Ethernet-адрес. После получения ответа на свой ARP-запрос машина имеет требуемую информацию о соответствии IP и Ethernet-адресов, формирует элемент ARP-таблицы и отправляет IP-пакет, ранее поставленный в очередь. Если же в сети нет машины с искомым IP-адресом, то ARP-ответа не будет. Модуль IP будет уничтожать IP-пакеты, предназначенные для отправки по этому адресу.

Протоколы верхнего уровня не могут отличить случай повреждения в среде Ethernet от случая отсутствия машины с искомым IP-адресом. Во многих реализациях в случае, если IP-адрес не принадлежит локальной сети, внешний порт сети (gateway) или маршрутизатор откликается, выдавая свой физический адрес (режим проксиARP).

Функционально, ARP делится на две части. Одна определяет физический адрес при посылке пакета, другая отвечает на запросы других машин. ARP-таблицы имеют динамический характер, каждая запись в ней "живет" определенное время, после чего удаляется. Менеджер сети может осуществить запись в ARP-таблицу, которая там будет храниться "вечно". ARP-пакеты вкладываются непосредственно в Ethernetкадры. Формат ARP-пакета показан на рис. 5.9.

HALen — длина аппаратного адреса; PALen — длина протокольного адреса (длина в байтах, например, для IP-адреса PALen=4 ). Тип оборудования — это тип интерфейса, для которого отправитель ищет адрес; код содержит 1 для Ethernet. Ниже представлена таблица 5.4 кодов оборудования.

Поле код операции определяет, является ли данный пакет ARP-запросом (код = 1), ARP-откликом (2), RARP-запросом (3), или RARP-откликом (4).

ARP-таблицы строятся согласно документу RFC-1213 и для каждого IP-адреса содержит четыре кода (таблица 5.5.1.).

В SUN и некоторых других ЭВМ имеется программа arp, которая позволяет отобразить ARP-таблицу на экране. С флагом a команда отображает всю таблицу, флаг d позволяет стереть запись, а s служит для внесения записей в таблицу (последние два флага доступны для операторов с системными привилегиями). Команда ARP без флагов с адресом или именем ЭВМ выдаст соответствующую строку таблицы.

arp 192.148.166.129
Name: semenov.itep.ru
Address: 192.148.166.129
Aliases: yas

А команда

arp nb

выдаст запись

nb (193.124.224.60) at 0:80:ad:2:24:b7 (запись для NetBlazer ИТЭФ)

ARP запросы могут решать и другие задачи. Так при загрузке сетевого обеспечения ЭВМ такой запрос может выяснить, а не присвоен ли идентичный IP-адрес какомуто еще объекту в сети. При смене физического интерфейса такой запрос может инициировать смену записи в ARP-таблице.

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

Самообращенный запрос позволяет ЭВМ решить две проблемы. Во­первых, определить, нет ли в сети объекта, имеющего тот же IРадрес. Если на такой запрос придет отклик, то ЭВМ выдаст на консоль сообщение Duplicate IP address sent from Ethernet address <...>. Во­вторых, в случае смены сетевой карты производится корректировка записи в АRP-таблицах ЭВМ, которые содержали старый МАС-адрес инициатора. Машина, получающая ARP-запрос c адресом, который содержится в ее таблице, должна обновить эту запись.

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

5.2. Протокол обратного адресного преобразования RARP

Обычно IP-адреса хранятся на диске (в конфигурационных файлах), откуда они считываются при загрузке системы. Проблема возникает тогда, когда необходимо инициализировать рабочую станцию, не имеющую диска. Бездисковые системы часто используют операции типа TFTP для переноса из сервера в память образа операционной системы, а это нельзя сделать, не зная IP-адресов сервера и ЭВМ-клиента. Записывать эти адреса в ПЗУ не представляется целесообразным, так как их значения зависят от точки подключения ЭВМ и могут меняться. Для решения данной проблемы был разработан протокол обратной трансляции адресов (RARP – Reverse Address Resolution Protocol, RFC-0903, смотри также ниже описание протокола BOOTP). Форматы сообщений RARP сходны с ARP (см. рис. 5.10), хотя сами протоколы принципиально различны. Протокол RARP предполагает наличие специального сервера, обслуживающего RARPзапросы и хранящего базу данных о соответствии аппаратных адресов протокольным. Этот протокол работает с любой транспортной средой, в случае же кадра Ethernet в поле тип будет записан код 803516 (смотри таблицу 5.5).

Здесь обозначения те же, что и в описании ARP-формата. Значение n определяется числом, записанным в поле HA-Len, а m — числом из поля PALen. Для Internet PA-Len=4 и тип протокола=2048, а для Ethernet равно HA-Len=6 и тип оборудования=1. В RARP используется два кода операции. Код операции=3 используется для RARP-запросов, а код операции=4 — для RARP-откликов. В первом случае поле протокольный адрес отправителя и протокольный адрес адресата не определены. Обычно локальная сеть имеет несколько RARP-серверов, что позволяет загрузиться бездисковым машинам, даже если какой­то из серверов выключен или не исправен.