24. Файлы основного архива dns сервера. Структура файла базы данных.
DNS существовала не с момента рождения TCP/IP сетей. Поначалу для облегчения взаимодействия с удаленными информационными ресурсами в Интернет стали использовать таблицы соответствия числовых адресов именам машин.
Авторство создания этих таблиц принадлежит доктору Постелю (Dr. Jon Postel - автор многих RFC - Request For Comments). Именно он первым поддерживал файл hosts.txt, который можно было получить по FTP.
Современные операционные системы тоже поддерживают таблицы соответствия IP-адреса и имени машины (точнее хоста) - это файлы с именем hosts. Если речь идет о системе типа Unix, то этот файл расположен в директории /etc и имеет следующий вид:
127.0.0.1 localhost
144.206.130.137 polyn Polyn polyn.net.kiae.su polyn.kiae.su
144.206.160.32 polyn Polyn polyn.net.kiae.su polyn.kiae.su
144.206.160.40 apollo Apollo www.polyn.kiae.su
Пользователь для обращения к машине может использовать как IP-адрес машины, так и ее имя или синоним (alias). Как видно из примера, синонимов может быть много, и, кроме того, для разных IP-адресов может быть указано одно и то же имя.
Напомним еще раз, что по самому мнемоническому имени никакого доступа к ресурсу получить нельзя. Процедура использования имени заключается в следующем:
сначала по имени в файле hosts находят IP-адрес,
затем по IP-адресу устанавливают соединение с удаленным информационным ресурсом.
Обращения, приведенные ниже аналогичны по своему результату - инициированию сеанса telnet с машиной Apollo:
telnet 144.206.160.40
или
telnet Apollo
или
telnet www.polyn.kiae.su
В локальных сетях файлы hosts используются достаточно успешно до сих пор. Практически все операционные системы от различных клонов Unix до Windows последних версий поддерживают эту систему соответствия IP-адресов именам хостов.
Однако такой способ использования символьных имен был хорош до тех пор, пока Интернет был маленьким. По мере роста Сети стало затруднительным держать большие согласованные списки имен на каждом компьютере. Главной проблемой стал даже не размер списка соответствий, сколько синхронизация его содержимого. Для того, что бы решить эту проблему, была придумана DNS.
DNS была описана Полом Мокапетрисом (Paul Mockapetris ) в 1984. Это два документа: RFC-882 и RFC-883 (Позже эти документы были заменены на RFC-1034 и RFC-1035). Пол Мокапетрис написал и реализацию DNS - программу JEEVES для ОС Tops-20. Именно на нее в RFC-1031 предлагается перейти администраторам машин с ОС Tops-20 сети MILNET. Не будем подробно излагать содержание RFC-1034 и RFC-1035. Ограничимся только основными понятиями.
Роль имени (доменного имени) в процессе установки соединения осталось прежним. Это значит, что главное, для чего оно нужно, - получение IP адреса. Соответственно этой роли, любая реализация DNS является прикладным процессом, который работает над стеком протоколов межсетевого обмена TCP/IP. Таким образом, базовым элементом адресации в сетях TCP/IP остался IP-адрес, а доменное именование (система доменных имен) выполняет роль вспомогательного сервиса.
Система доменных имен строится по иерархическому принципу. Точнее по принципу вложенных друг в друга множеств. Корень системы называется "root" (дословно переводится как "корень") и никак не обозначается (имеет пустое имя согласно RFC-1034).
Часто пишут, что обозначение корневого домена - символ ".", но это не так, точка - разделитель компонентов доменного имени, а т.к. у корневого домена нет обозначения, то полное доменное имя кончается точкой. Тем не менее символ "." достаточно прочно закрепился в литературе в качестве обозначения корневого домена. От части это вызвано тем, что в файлах конфигурации серверов DNS именно этот символ указывается в поле имени домена (поле NAME согласно RFC-1035) в записях описания ресурсов, когда речь идет о корневом домене.
Корень - это все множество хостов Интернет. Данное множество подразделяется на домены первого или верхнего уровня (top-level или TLD). Домен ru, например, соответствует множеству хостов российской части Интернет. Домены верхнего уровня дробятся на более мелкие домены, например, корпоративные.
Пространство имен домена и записи базы данных Спецификация Структура пространства имен домена представляет из себя "дерево". Каждый узел сети (или лист этого "дерева") обозначает ресурс системы, который реально может и не существовать. Узел имеет метку, длина которой может достигать 63 байт. Метка с нулевой длиной используется для обозначения корня дерева, т. е. данного домена. Пример древовидного пространства имен домена приведен на рис.5.
Рис.5. Пример древовидного пространства имен домена Полное имя домена представляет собой путь от данного узла к корню "дерева", составленный из меток доменов старших уровней, т. е. доменов, расположенных ближе к корню "дерева" в системе иерархии доменов. Имя домена представляет собой строку из ASCII-символов верхнего или нижнего регистра первой половины таблицы символов (до 128). Полное имя состоит из меток доменов (данного домена и всех родительских), отделенных друг от друга символом ".". Данный домен может представлять собой субдомен от "родительских" доменов. Например, A.B.C.D — субдомен домена B.C.D, субдомен доменов C.D, D и корневого домена. К данному домену можно обращаться через полное (абсолютное) имя, например, "silly.tamu.edu", или через имя внутри домена — родителя, например, "silly", когда мы находимся внутри домена "tamu.edu". Длина полного имени домена, т. е. сумма длин всех меток пути ограничена 255 байтами. Древовидная структура имен доменов подразумевает распараллеливание областей управления частями этой структуры между организациями. Потенциально, каждый узел "дерева" может являться родителем неограниченного числа новых субдоменов. Однако на практике это ограничивается администраторами серверов имен. Техническая спецификация DNS не указывает, каким образом строить то или иное пространство имен для данной системы доменов — это предоставляется сетевым администраторам системы. Она описывает только наиболее общие принципы построения, которые могут использоваться для работы с DNS программными приложениями, т. к. разные части дерева могут иметь различную семантику и использоваться приложениями для различных целей. В примере, приведенном на рис.5, корневой домен содержит три субдомена: MIL, EDU и ARPA. Домен LCS.MIT.EDU содержит один субдомен XX.LCS.MIT.EDU. Все "листья" "дерева" также являются доменами. Записи базы данных Имя домена идентифицирует ресурс системы. Эта ассоциация хранится в базе данных DNS виде отдельной записи — resource records (RRs), компоненты которой представлены на рис. 6.
Рис.6. Компоненты записи RR NAME (255 байт). Имя, которое идентифицирует ресурс. Имя ресурса содержит имя домена (или хоста пользователя), в котором расположен этот ресурс, т. е. "владельца" информации. Например, RR, которая содержит IP-адрес хоста, содержит и имя домена, в котором расположен этот адрес. (Серверы имен хранят информацию о ресурсе в древовидной структуре параллельно со структурой пространства имен в базе данных.) TYPE (2 байта). Тип ресурса. Тип обозначает группу принадлежности ресурса, например, адрес хоста или идентификатор почтового роутера. CLASS (2 байта). Поле класса ресурса. Поле класса идентифицирует формат данных ресурса. Например, принадлежит ресурс IP-адреса хоста к ARPA Internet (класс "IN") или к Computer Science Network format (класс "CSNET"). Необходимо отметить, что для разных типов ресурса класс ресурса может означать разное. Например, класс IN использует только 32-битные IP-адреса, а класс CSNET использует как 32-битные IP-адреса, так и адреса Х25 и номера телефонов. То есть поле класса используется как указатель того, как использовать информацию, хранящуюся в данном ресурсе. TTL (32 бита). Параметр, используемый для управления RR. TTL задает временной интервал продолжительности нахождения данной записи в кэше системы (в секундах). При просмотре этой записи в кэше данный интервал уменьшается, и если он становится меньше или равным нулю — данная запись в кэше системы уничтожается. Если данное поле пустое, то в качестве TTL берется значение поля Minimum, задаваемое в записи SOA. LENGTH (32 бита). Длина поля данных. Это поле позволяет серверу имен или программе разрешения имен домена определить границы данных, даже если они не в состоянии интерпретировать содержимое поля данных. DATA. Данные ресурса. Максимальная длина поля — 65535 байт. Формат представления данных определяется полями типа и класса. Поле типа может принимать одно из следующих значений (в таблицу включены наиболее распространенные типы записей):
Кроме перечисленных выше, тип может принимать и другие значения. Часть из них устарела и заменилась на другие (например, MD и MF были заменены на MX), а часть используется очень редко. Класс означает принадлежность записи к определенной системе, тогда как тип определяет функциональность записи в этой системе. Например, сеть Internet определена значением поля класса = 1, и обозначением "IN" — Internet, а сеть CHAOS значением класса = 3, и обозначением "СН". Для типа "А" класса "IN" поле данных будет содержать 32-битный IP-адрес, а для того же типа класса "СН" (система CHAOS) — имя домене CHAOS, следующее за 16-битным адресом CHAOS. Как уже было сказано, формат поля данных во многом зависит от типа записи. Ниже представлены форматы полей данных ресурса для класса "IN' некоторых типов RR.
0 15
CNAME
Рис.7. Запись с ресурсом типа CNAME
|
|
Тип "HINFO". Запись с ресурсом типа HINFO (рис.8) служит для хранения информации о хосте, например, об аппаратной платформе и операционной системе компьютера. CPU тип — строка, OS тип — строка. |
0 |
15 |
CPU |
OS |
Рис. 8. Запись с ресурсом типа HINFO
|
Тип "MX". Для отдельных хостов или всего домена запись с ресурсом типа MX (рис.9) позволяет определить почтовый шлюз — компьютер, куда будет направляться электронная почта, предназначенная для этих хостов. Поле данных состоит из 16-битного значения приоритетности почтового роутера, задает приоритет доставки. При этом ноль означает самый высокий приоритет, и строки — имени хоста, работающего как почтовый роутер.
|
0 |
15 |
PREFERENCE |
EXCHANGE |
Рис. 9. Запись с ресурсом типа MX
|
Тип "NS". Запись с ресурсом типа NS (рис.10) обозначает имя хоста, являющегося первичным сервером имен для домена. Поле данных содержит имя хоста |
0 |
15 |
NSDNAME |
Рис. 10. Запись с ресурсом типа NS
|
Тип "SOA": параметры зоны. Запись с ресурсом типа SOA (рис.11) обозначает начало зоны управления сервера имен. Зона управления действует до следующей записи SOA. Пакет данных содержит: MNAME — имя родительского домена данной зоны; RNAME — имя домена, обозначающее почтовый ящик администратора зоны; SERIAL — 32-битный идентификатор зоны; REFRESH — 32-битное значение интервала времени (в секундах), через который содержание зоны должно обновляться; RETRY — 32-битный интервал (в секундах) повторения запросов обновления содержания зоны в случае неудачи операции обновления; EXPIRE — 32-битный интервал (в секундах) продолжительности полномочий домена в зоне; MINIMUM — 32-битное значение (в секундах) минимального значения TTL, которое устанавливается в сообщениях ответа в данной зоне на запросы, если у запрашиваемой записи параметр TTL не установлен в большее значение. |
0 |
15 |
MNAME |
|
|
RNAME |
|
|
SERIAL |
|
|
REFRESH |
|
|
RETRY |
|
|
EXPIRE |
|
|
MINIMUM |
|
|
|
|
|
Рис. 11. Запись с ресурсом типа SOA
|
|
Тип "WKS". Запись с ресурсом типа WKS (рис.12) используется для описания широко известных сервисов, поддерживаемых определенным протоколом, хостом, расположенным по определенному адресу (поле ADDRESS — 32 бита). Поле PROTOCOL (8 бит) специфицирует тип протокола, а битовое поле (<BIT MAP> — переменной длины) определяет порт сервиса, работающий по данному протоколу: каждый бит поля, равный 1, определяет активный порт (если бит, соответствующий номеру порта отсутствует, считается, что он равен 0). Например, если PROTOCOL=6 (TCP), а 26-ой бит поля установлен в 1, это означает, что данный хост слушает 25-й (SMTP) порт протокола TCP. Запись WKS создается на каждый протокол, с которым работает хост. |
|
|
0 |
8 |
15 |
ADDRESS |
|
PROTOCOL |
BIT MAP |
BIT MAP |
|
Рис.12. Запись с ресурсом типа WKS