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

Главной ЭВМ любой системы является та, на которой работаете вы. Но помимо этой машины и маршрутизатора локальной сети, не последнюю роль играет сервер имен (DNS-система, RFC-4032, -4034, -4035, -2137, -2052, -2136, -1996, -1918, -1793, -171213, -1706, -1664, -161112, -153637, -1401, -1383, -1183, -1101, -103435).

Сервер имен — это программа управления распределенной базой данных, в которой хранятся символьные имена сетей, различных сетевых объектов и ЭВМ вместе с их IP-адресами.

Наиболее распространенным программным продуктом, решающим данную задачу является BIND (Berkeley Internet Name Domain). Иногда для этой цели выделяют специальную машину. Задача DNS — преобразование символьного имени в IP-адрес и, наоборот, в условиях, когда число узлов Internet растет экспоненциально, совсем не проста. Сама иерархическая система имен (DNS) настроена на упрощение решения этой проблемы. Схема взаимодействия программы пользователя с локальным и удаленными DNSсерверами показана ниже на рисунке 5.1.

Рис. 5.1. Структура взаимодействия с серверами имен

База имен является распределенной, так как нет такой ЭВМ, где бы хранилась вся эта информация. Имя содержит несколько полей (длиной не более 63 символов), разделенных точками, а его полная длина не должна превышать 255 октетов, включая байт длины. Анализ имени производится справа налево. Самая правая секция имени характеризует страну или характер организации: образовательная, коммерческая, правительственная и т.д..

Следующие символьные коды в конце Internet-имени означают функциональную принадлежность узла (таблица 5.1.).

Секции .mil и .gov принадлежат исключительно американским сетям (хотя и многие другие трехсимвольные секции адреса, например .edu, чаще, но не всегда, принадлежат американским университетам и другим учебным организациям). Структура имен обычно отражает структуру организации, которой принадлежат сети или ЭВМ, но не архитектуру сети в этой организации. Так имя itep.ru — это имя домена itepnet (Институт Теоретической и Экспериментальной физики, Москва). cl.itep.ru — имя mvax-кластера в ИТЭФ, а suncom.itep.ru — имя одной из ЭВМ SUN в той же сети. По имени, как правило, нельзя определить, является ли оно именем сети, маршрутизатора или конкретной ЭВМ. Для записи символьных имен используется исключительно латинский алфавит.

Маленький фрагмент интернетовской иерархии имен показан на рис. 5.2. Число уровней реально больше, но обычно не превышает 5.

Рис. 5.2. Иерархия имен в Интернет­DNS (I — домен первого уровня; II — второго уровня)

Каждому узлу (прямоугольнику на рисунке) соответствует имя, которое может содержать до 63 символов. Только самый верхний, корневой узел не имеет имени. При написании имени узла строчные и прописные символы эквивалентны. Имя домена, завершающееся точкой, называется абсолютным или полным именем домена (например, itep.ru.). В некоторых странах создана структура имен, сходная с com/edu/org. Так, в Англии можно встретить адреса .ac.uk для академических учреждений и .co.uk — для коммерческих. Если имя домена не завершено символом точки, DNS может попытаться его дополнить, например, имя ns может быть преобразовано в ns.itep.ru. На приведенной схеме каждому объекту трех верхних уровней соответствуют серверы имен, которые могут взаимодействовать друг с другом при решении задачи преобразования имени в IP-адрес. Можно было бы построить схему, при которой в любом сервере имен имелись адреса серверов .com, .edu, .ru и т.д. и при необходимости он мог бы послать туда запрос. Реальная схема серверов не столь идеальна и стройна — существуют серверы nsf.gov, oakland.edu и т.д., которые непосредственно связаны с базовым сервером имен. Каждый сервер содержит лишь часть дерева имен. Эта часть называется зоной ответственности сервера. DNSсервер может делегировать ответственность за часть зоны другим серверам, создавая субзоны. Когда в зоне появляется новая ЭВМ или субдомен, администратор зоны записывает ее имя и IP-адреса в базу данных сервера. Администратор зоны определяет, какой из DNSсерверов имен является для данной зоны первичным. Число вторичных серверов не лимитировано. Первичный и вторичный серверы должны быть независимыми и работать на разных ЭВМ, так, чтобы отказ одного из серверов не выводил из строя систему в целом. Отличие первичного сервера имен от вторичного заключается в том, что первичный загружает информацию о зоне из файлов на диске, а вторичный получает ее от первичного сервера. Администратор вносит любые изменения в соответствующие файлы первичного сервера, а вторичные сер веры получают эту информацию, периодически (раз в 3 часа) запрашивая первичный сервер. Пересылка информации из первичного во вторичные серверы имен называется зонным обменом. Как будет вести себя сервер, если он не имеет запрашиваемой информации? Он должен взаимодействовать с корневыми серверами. Таких серверов насчитывается около десяти и их IPадреса должны содержаться в конфигурационных файлах.

Список корневых серверов вы можете получить с помощью анонимного FTP по адресам: nic.ddn.mil или ftp.rs.internic.net. Корневые серверы хранят информацию об именах и адресах всех серверов доменов второго уровня. Существует два вида запросов: рекурсивные и итеративные. Первый вид предполагает получение клиентом IP-адреса, а второй — адреса сервера, который может сообщить адрес. Первый вид медленнее, но дает сразу IP-адрес, второй эффективнее — в вашем сервере копится информация об адресах серверов имен. Одним из способов повышения эффективности трансляции имен в адреса является кэширование, то есть хранение в оперативной памяти именадресов, которые использовались последнее время особенно часто. Рассмотрение процесса обмена между ЭВМклиентом и сервером имен может прояснить работу системы в целом. Прежде чем использовать протоколы UDP или TCP, прикладная программа должна узнать IP-адрес объекта, куда она хочет послать дейтограмму. Для решения этой задачи программа посылает запрос в локальный сервер имен. В Unix-системах имеются специальные библиотечные процедуры gethostbyname и gethostbyaddr, которые позволяют определить IP-адрес по имени ЭВМ и наоборот. В одном запросе может содержаться несколько вопросов. Если сервер не сможет ответить на вопросы, он пришлет отклик, где содержатся адреса других серверов, способных решить эту задачу. Ниже на рисунке 5.3 представлен формат таких сообщений (в качестве транспорта используется UDP или TCP, порт 53).

Рис. 5.3. Формат DNS-сообщений

Каждое сообщение начинается с заголовка, который содержит поле идентификация, позволяющее связать в пару запрос и отклик. Поле флаги определяет характер запрашиваемой процедуры, а также кодировку отклика. Поля число... определяют число записей соответствующего типа, содержащихся в сообщении. Так, число запросов задает число записей в секции запросов, требующих ответов. Каждый вопрос состоит из символьного имени домена, за которым следует тип запроса и класс запроса. Значения битов поля флаги в сообщении сервера имен отображены в таблице 5.2. Разряды пронумерованы слева направо, начиная с нуля рис. 5.4.

Рис. 5.4. Назначение битов поля флаги

Ниже описан формат секции запросов в DNSсообщении.

Поле символьное имя домена имеет переменную длину, содержит одно или более субполей, начинающихся с байта длины (0-63). Поле завершается 0. Например, для ns.itep.ru (цифры представляют собой октеты длины).

Рис. 5.5. Формат секции вопросов DNS-запроса.

В реальной нотации байты длины субполя могут иметь два старших бита, равные 1, что преобразует интервал значений из 0-63 в 192-255. Такой байт в поле означает, что это не мера длины секции, а 16-битный указатель, 14 бит которого являются смещением от начала DNS-сообщения, указывающим на место продолжения секции. Смещение для первого байта поля идентификации равно нулю. Эти ухищрения придуманы для сокращения длины сообщений, так как одно и то же имя домена в отклике может повторяться много раз. Поле тип запроса характеризует разновидность запроса.