|
|
Система доменов и распределенная база данных DNSДля обращения к хостам в сети Internet используются 32-разрядные IP-адреса, однозначно идентифицирующие любой сетевой компьютер. Однако для пользователей применение IP-адресов при обращении к хостам не очень удобно. Поэтому в Internet принято присваивать имена всем компьютерам. Использование имен дает пользователю возможность лучше ориентироваться в кибер-пространстве Internet — куда проще запомнить, например, имя www.foyota.com, чем четырехзвенную цепочку IP-адреса. Применение в Internet понятных для пользователей имен и породило проблему их преобразования в IP-адреса. Такое преобразование необходимо, так как на сетевом уровне адресация пакетов осуществляется не по именам, а по IP-адресам, следовательно, для непосредственной адресации сообщений в Internet имена не годятся. Поэтому была создана новая система преобразования имен, позволяющая пользователю, в случае отсутствия у него информации о соответствии имен и IP-адресов, получить необходимые сведения. Эта система получила название системы имен доменов — DNS (Domain Name System). DNS (Domain Name System) - это распределенная база данных, поддерживающая иерархическую систему имен для идентификации узлов в сети Internet. Служба DNS предназначена для автоматического поиска IP-адреса по известному символьному имени узла. Спецификация DNS определяется стандартами RFC 1034 и 1035. DNS требует статической конфигурации своих таблиц, отображающих имена компьютеров в IP-адрес. Для реализации системы DNS был создан специальный сетевой протокол DNS. Кроме того, в сети создавались специальные выделенные информационно-поисковые серверы — DNS-серверы. Протокол DNS является служебным протоколом прикладного уровня. Этот протокол несимметричен - в нем определены DNS-серверы и DNS-клиенты. DNS-серверы хранят часть распределенной базы данных о соответствии символьных имен и IP-адресов. Эта база данных распределена по административным доменам сети Internet. Клиенты сервера DNS знают IP-адрес сервера DNS своего административного домена и по протоколу IP передают запрос, в котором сообщают известное символьное имя и просят вернуть соответствующий ему IP-адрес. Если данные о запрошенном соответствии хранятся в базе данного DNS-сервера, то он сразу посылает ответ клиенту, если же нет - то он посылает запрос DNS-серверу другого домена, который может сам обработать запрос, либо передать его другому DNS-серверу. Все DNS-серверы соединены иерархически, в соответствии с иерархией доменов сети Internet. Клиент опрашивает эти серверы имен, пока не найдет нужные отображения. Этот процесс ускоряется из-за того, что серверы имен постоянно кэшируют информацию, предоставляемую по запросам. Клиентские компьютеры могут использовать в своей работе IP-адреса нескольких DNS-серверов, для повышения надежности своей работы. База данных DNS имеет структуру дерева, называемого доменным пространством имен, в котором каждый домен (узел дерева) имеет имя и может содержать поддомены. Имя домена идентифицирует его положение в этой базе данных по отношению к родительскому домену, причем точки в имени отделяют части, соответствующие узлам домена. Корень базы данных DNS управляется центром Internet Network Information Center. Домены верхнего уровня назначаются для каждой страны, а также на организационной основе. Имена этих доменов должны следовать международному стандарту ISO 3166. Для обозначения стран используются трехбуквенные и двухбуквенные аббревиатуры, а для различных типов организаций используются следующие аббревиатуры: com - коммерческие организации (например, microsoft.com); edu - образовательные (например, mit.edu); gov - правительственные организации (например, nsf.gov); org - некоммерческие организации (например, fidonet.org); net - организации, поддерживающие сети (например, nsf.net). В целях предоставления зарубежным странам, чьи сети входят в INTERNET, возможности контроля за именами находящихся в них систем создан набор 2-х буквенных доменов, которые соответствуют доменам высшего уровня для этих стран. Например: au для Австралии ca для Канады cn для Китая fi для Финляндии fr для Франции se для Швеции и т.д. Общее число кодов стран - 300; компьютерные сети существуют приблизительно в 150 из них. Следует отметить, что США имеют свой собственный код страны, хотя он широко не иcпользуется. В США большинство систем пользуются “организационными” доменами (типа edu ), а не “географическими”( типа va.us - штат Вирджиния). Каждый домен DNS администрируется отдельной организацией, которая обычно разбивает свой домен на поддомены и передает функции администрирования этих поддоменов другим организациям. Каждый домен имеет уникальное имя, а каждый из поддоменов имеет уникальное имя внутри своего домена. В имени может быть любое число доменов, но более пяти встречается редко. Каждый последующий домен в имени (если смотреть слева направо) больше предыдущего. Имя домена может содержать до 63 символов. Каждый хост в сети Internet однозначно определяется своим полным доменным именем (fully qualified domain name, FQDN), которое включает имена всех доменов по направлению от хоста к корню. Особенности использования доменных именПри анализе доменных имен компьютеров следует учитывать следующие особенности их использования:
Состав и основные элементы DNSDNS имеет три основные компоненты:
Работа системы DNS в целом может представляться по-разному:
Примечание В целях увеличения производительности, сервер имен и программы разрешения имен на одной машине могут частично выполнять функции друг друга и разделять доступ к базе данных. Основным предназначением системы имен домена является обеспечение работы механизма именования ресурсов. Этот механизм должен работать с различными хостами, сетями, семействами протоколов и типами организаций. Описанная выше функциональная структура DNS позволяет изолировать проблемы отдельных модулей системы, и, тем самым, создает универсальную модульную архитектуру, пригодную для работы в гетерогенных средах. Хост может участвовать в работе системы доменов различными способами, в зависимости от типа программного обеспечения и требуемой информации, Пользователь взаимодействует с пространством имен через программы разрешения. Запросы пользователя представляют собой вызовы функций программы разрешения (или системных функций, если программа разрешения составляет часть операционной системы) с соответствующими параметрами. Программа разрешения отвечает на запросы пользователей на основании имеющейся у нее в кэше информации или переадресовывает запросы на Другие серверы имен. Программа разрешения может отправить несколько запросов на несколько серверов имен одновременно. Простейший и наиболее распространенный способ работы с серверами имен показан на рис. 1.
Рис. 1. Простейший способ работы с серверами имен Сервер имен может работать как отдельная программа (процесс) на выделенной машине, которая специально для этого предназначена. Представленный на рис.2 сервер имен обрабатывает запросы на основании информации из файлов главного архива локальной системы.
Рис.2. Схема работы сервера имен с локальной базой имен Система DNS требует, чтобы доступ к информации определенной зоны мог быть осуществлен с нескольких серверов имен. Серверы, имеющие доступ к данной зоне, должны синхронизировать информацию, используя механизм перемещения зон DNS. На схеме, приведенной на рис.3, сервер имен периодически устанавливает виртуальное соединение с другим сервером и синхронизирует информацию общих зон. Протокол синхронизации почти такой же, что используется при запросах пользователей.
Рис.3. Схема взаимодействия двух серверов имен Показанная на схеме (рис.4) разделяемая база данных хранит данные пространства имен, которые состоят из записей, поступающих с операциями обновления и кэшированных данных запросов.
Рис.4. Схема полной функциональности DNS Пространство имен домена и записи базы данныхСтруктура пространства имен домена представляет из себя "дерево". Каждый узел сети (или лист этого "дерева") обозначает ресурс системы, который реально может и не существовать. Узел имеет метку, длина которой может достигать 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.
Рис.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
Записи RR хранятся в базе данных DNS и передаются в пакетах DNS-протокола в двоичном виде. Однако, как известно, RRs модифицируются администратором в файлах главного архива в текстовом формате. Текстовый формат представления состояния базы данных значительно упрощает процедуры вставки, модификации или удаления записей.
Текстовый файл содержит последовательность записей, которые располагаются в строчки, заканчивающиеся символом перевода строки — <CRLF>. Для размещения информации на нескольких строках используются скобки. Ниже перечислены некоторые из этих символов, имеющих специальное значение:
|
Символы |
Значение |
|
. |
Отдельно стоящая точка в поле name обозначает текущий домен |
|
@ |
Отдельно стоящий символ "@" в поле name обозначает текущий исходный домен |
|
( ) |
Скобки используются для размещения поля data на нескольких строках (когда поле data занимает несколько строк) |
|
* |
Метасимвол. Заменяет любой набор символов |
|
; |
Символ комментария. От этого символа и до конца строки информация игнорируется. |
Примечание
В записях ресурсов доменное имя, не заканчивающееся точкой, считается относительным. При обработке оно прибавляется к текущему домену. Поэтому, когда задается полное имя, его необходимо заканчивать точкой.
Общая структура файла выглядит следующим образом:
<domain-name><RR> [; <coniment>]
<blank><RR> [ ;<comrnent>]
<blank>[;<comment>]
$INCLUDE <file-name> [<domain-name>] ;[<cominent>]
|
<blank> — пустая строка, символы "пробела" или табуляции. |
|
<domain-name> — имя домена — владельца записи. Как правило, в текстовом файле запись (строка) RR начинается с идентификатора владельца данной записи. Если поле domain-name пустое, то в качестве него используется последнее заданное в предыдущих записях поле domain-name, т. е. предполагается, что данная запись относится к предыдущему имени домена (как правило, для удобства чтения, добавляется несколько пробелов и делается выравнивание столбцов). |
|
SINCLUDE — вставляет имя файла имен в текущий файл имен (и может содержать имя домена, который описан в добавленном файле). |
|
<RR> — информационная запись файла имеет следующий формат: |
[<TTL>] [<class>] <type> <RDATA>
[<class>] [<TTL>] <type> <RDATA>
|
запись может начинаться с поля TTL и поля класса. Как правило, эти параметры для всех записей одного файла (зоны) принимают одно и то же значение, и определяются только один раз — в записи определения зоны, располагающейся в начале файла имен |
|
далее следуют поля типа записи и данных |
|
поле TTL записывается как целое число. Для того чтобы избежать неопределенности при синтаксическом разборе, мнемоники типа и класса различаются, TTL всегда представляет собой число, а мнемоника типа всегда последняя из этих трех полей |
|
завершает строку поле данных ресурса |
Ниже приведен пример текстового представления части зоны "дерева" домена ISI.EDU.
NS A.ISI.EDU.
NS VAXA
MX 20 VAXA
A A 26.3.0.103
VAXA A 10.2.0.27
А 128.9.0.33
$INCLUDE <SUBSYS>ISI-MAILBOXES.TXT
где файл <SUBSYS>ISI-MAILBOXES.TXT может содержать, например, следующее:
МОЕ MX A.ISI.EDU.
LARRY MX A.ISI.EDU.
STOOGES MX МОЕ
MX CURLEY
В данном примере не указан класс IN и поле TTL, которые подразумеваются одинаковыми. В следующем примере показаны два адреса домена XX.LCS.MIT.EDU, принадлежащие различным классам с полем TTL = 17777.
XX.LCS.MIT.EDU. 17777 IN A 10.0.0.44
17777 CH A MIT.EDU. 2420
В больших системах хосты, почтовые роутеры или почтовые ящики и др. сетевые ресурсы часто имеют по несколько имен. Например, имена C.ISI.EDU и USC-ISIC.ARPA принадлежат одному и тому же хосту, а почтовые ящики Mockapetris@C.ISI.EDU, Mockapetris@B.ISI.EDU и PVM@ISI.EDU адресуют один и тот же объект.
Для этих целей и используется тип записи CNAME. Этот тип определяет псевдоним объекта к которому он относится. Ясно, что псевдоним не может иметь какой-либо другой спецификации, поскольку данные для псевдонима объекта и самого объекта не могут различаться.
Присутствие типа CNAME предполагает выполнение сервером имен определенных дополнительных действий. Например, если сервер не смог найти какую-либо информацию по указанному имени, он проверяет записи типа CNAME данного класса. Если у указанного в запросе имени есть псевдоним — поиск повторяется по данному псевдониму (при повторном проходе записи типа CNAME уже не просматриваются).
Например, если сервер имен обрабатывает запрос адреса имени FUN.MAN.ARPA, а база данных содержит следующие записи:
FUN.MAN.ARPA IN CNAME JOLLY.EDU
JOLLY.EDU IN A 10.0.0.12
обе эти записи возвращают в ответ на запрос адреса как по имени FUN.MAN.ARPA, так и по имени JOLLY.EDU значение 10.0.0.12.
Примечание
Имена доменов, указывающие на имя другого домена, должны использовать только реальное имя, а не псевдоним. Например, имя адреса домена JOLLY.EDU, описанного в примере, должно быть записано в следующем виде:
12.0.0.10.IN-ADDR.ARPA IN PTR JOLLY.EDU
Запросы представляют собой сообщения, которые отправляются серверу имен и на которые он должен ответить. Запросы передаются через дейтаграммы UDP (порт 53) или соединения TCP (порт 53). Выбор протокола осуществляется в зависимости от требований операции к скорости и достоверности передаваемых данных.
Например, протокол UDP используется для построения стандартных запросов Internet, но не используется для операций перемещения зоны, поскольку в первом случае важна скорость выполнения операции, а во втором — надежность соединения для передачи данных. Кроме того, UDP позволяет установить более гибкий контроль интервалов повторной передачи потерянных пакетов. TCP используется, например, когда сервер одновременно работает с несколькими соединениями, или клиентская часть требует для передачи данных установки достоверного соединения. Ответ на запрос либо содержит требуемую информацию, либо переадресует запрос на другой сервер имен, либо сообщает о возникновении ошибки обработки или передачи запроса.
Запросы передаются в виде сообщений определенного формата. Сообщение состоит из заголовка, который содержит определенные управляющие поля, такие как поле кода операции (opcode), типа запроса, статуса запроса и др., и четырех секций для параметров записей RR, содержание которых зависит от кода операции запроса (рис.13).
|
Header |
|
Query |
|
Answer |
|
Authority |
|
Additional |
Рис.13.Структура сообщения DNS-протокола
Заголовок (Header). Содержит управляющие поля.
Запрос (Query). Содержит имя и другие параметры запроса.
Ответ (Answer). Содержит RR ответа на запрос.
Права (Authority). Содержит RR, описывающие другие полномочные для работы с данной RR серверы имен.
Дополнительные секции (Additional). Содержат дополнительную информацию. На рис.14 показана структура заголовка сообщения DNS-протокола.
| 0 | 8 | 15 |
|
ID | |||||||
|
QR |
OPCODE |
AA |
TC |
RD |
RA |
Z |
RCODE |
|
QDCOUNT | |||||||
|
ANCOUNT | |||||||
|
NSCOUNT | |||||||
|
ARCOUNT | |||||||
Рис.14. Структура заголовка сообщения DNS-протокола
ID (16 бит). Идентификатор цикла запрос-ответ. ID запроса копируется в поле сообщения ответа, которое, в свою очередь, может быть запросом следующей итерации первоначального запроса.
QR (1 бит). Флаг запроса или ответа (0 / 1). OPCODE (4 бита). Тип запроса (простои / инверсный / запрос статуса). АА (1 бит). Флаг уполномоченного ответа. RCODE (4 бита). Код статуса ответа. QDCOUNT (16 бит). Количество записей в секции запроса. ANCOUNT (16 бит). Количество записей в секции ответа. NSCOUNT (16 бит). Количество записей в секции уполномоченных серверов NS. ARCOUNT (16 бит). Количество записей в дополнительной секции.
Стандартный запрос (секция Query) содержит имя домена, информацию на который мы хотим получить (QNAME), тип запроса (QTYPE), класс запроса (QCLASS). Структура секции Query сообщения DNS-протокола представлен на рис. 15. Поля QTYPE и QCLASS по 16 бит каждое, содержат коды типа и класса записи RR, информацию о которой мы хотим получить.
| 0 | 15 |
|
QNAME |
|
QTYPE |
|
QCLASS |
Рис.15. Структура секции Query сообщения DNS-протокола
Используя параметры имени домена (хоста), типа и класса, сервер имен ищет в таблице базы данных соответствующие записи.
Например, хост — отправитель почты может сделать запрос о наличии в домене ISI.EDU почтовых роутеров, например, для отправки почты в этот домен. Параметры запроса будут следующими: QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN. В ответ хост получит пакет, содержащий в секции ответа (Answer) структуру записи RR (описание структуры см. выше), например, со следующей информацией:
ISI.EDU. MX 10 MARS.ISI.EDU.
MX 10 POMPA.ISI.EDU.
дополнительная секция ответа (Additional) может содержать, например, IP-адреса почтовых роутеров:
MARS.ISI.EDU. А 10.2.0.27
А 128.9.0.33
POMPA.ISI.EDU. A 10.1.0.52
А 128.9.0.32
Кроме обычных запросов существуют, так называемые, инверсные запросы. Их отличие от стандартных состоит в том, что они определяют имя домена (или доменов) по характеристикам определенного ресурса. Например, если стандартный запрос определяет записи SOA RR соответствующие имени домена, соответствующий инверсный запрос определяет имя домена по параметрам SOA RR.
Механизм инверсных запросов используется, например, для соотнесения IP-адресов и имен хостов Internet. Для соотнесения IP-адресов и имен хостов в Internet используется специальный домен IN-ADDR.ARPA. Записи в домене IN-ADDR.ARPA состоят из суффикса IN-ADDR.ARPA и четырех предшествующих ему меток. Каждая метка представляет собой байт Internet-адреса. Расположены метки в порядке, обратном расположению байт Internet-адреса. Например, если Internet-адрес домена 10.2.0.52, то в домене IN-ADDR.ARPA ему будет соответствовать запись 52.0.2.10.IN-ADDR.ARPA. Такое обратное представление адреса позволяет определять управляющие зоны и шлюзы для классов сетей.
Например, если домен IN-ADDR.ARPA содержит информацию о ISI-шлюзе между сетью 10 и 26, и имеет адреса 10.2.0.22 и 26.0.0.103, то база данных будет содержать следующие записи:
10.IN-ADDR.ARPA. PTR GW.ISI.EDU.
26.IN-ADDR.ARPA. PTR GW.ISI.EDU.
22.0.2.10.IN-ADDR.ARPA. PTR GW.ISI.EDU.
103.0.0.26.IN-ADDR.ARPA. PTR GW.ISI.EDU.
При использовании сервиса инверсных запросов следует иметь ввиду, что, поскольку домен IN-ADDR.ARPA и обычный домен данного хоста или шлюза расположены в различных зонах, возможно, что данные в этих доменах будут не согласованы, кроме того, шлюзы, как правило, имеют в разных доменах различные имена.
Предназначение механизма обратных запросов и домена IN-ADDR.ARPA состоит в том, чтобы по IP-адресу хоста можно было быстро определить домен и управляющие элементы домена, где расположен этот хост.
Все серверы имен должны понимать и распознавать как стандартные, так и инверсные запросы. Ясно, что инверсные запросы не могут гарантировать полноту и уникальность возвращаемой информации даже внутри определенного домена. Эти запросы, как правило, используются при инсталляции и тестировании различных компонент сервера имен.
Серверы имен управляют информацией, которую составляет база данных имен и адресов домена. База данных разделена на секции, называемые зонами, которые распределяются для обслуживания между различными серверами имен. Основной задачей серверов имен является обработка запросов на основе информации локальных зон, расположенных на данном хосте, или переадресация запроса на серверы, располагающие требуемой информацией.
Структура работы сервера имен во многом зависит от сетевой среды работы, операционной системы хоста и от структуры данных, которыми сервер управляет. Основной единицей базы данных пространства имен является зона.
Зона представляет собой полную спецификацию какой-либо части пространства имен домена. К данной зоне, как правило, имеют доступ несколько серверов имен. В соответствии с соглашением, каждая зона должна быть доступна, по меньшей мере, с двух серверов. Один сервер имен, как правило, поддерживает работу одной или более зон.
База данных домена может быть разбита на зоны двумя способами: по классам и "срезам" пространства имен.
|
Деление по классам. Для какого-либо класса строится и инсталлируется отдельная база данных. Поскольку пространство имен одно и то же для всех классов, структуры данных для отдельных классов можно рассматривать как параллельные "деревья" пространства имен. Ясно, что данные узлов этих "деревьев" будут зависеть от класса, которому они принадлежат. Причиной построения нового класса, как правило, является необходимость в новом формате данных, или требуется построить независимое (от уже существующего) пространство имен. |
|
Деление по "срезам". Внутри отдельного класса, "срез" в пространстве имен можно сделать между любыми двумя соседними узлами. После построения такого "среза" каждая группа пространства имен будет представлять собой отдельную зону. Такой "срез" в пространстве имен может проходить в разных классах по различным местам пространства имен, части новых зон могут принадлежать различным серверам имен и т. д. |
Эти правила деления подразумевают, что каждая зона имеет по крайней мере один узел и имя домена, пространством имен которого она владеет. Кроме того, в соответствии со структурой "дерева", каждая зона имеет своего "родителя" — зону, расположенную в системе иерархии ближе к корню "дерева". Имя зоны — родителя часто используется для определения имени данной зоны.
Безусловно, деление пространства имен таким образом, что каждый домен располагался бы в отдельной зоне или так, чтобы все узлы домена располагались бы в отдельной зоне, было удобно с точки зрения единого администрирования. Однако вместо этого база данных чаще всего разделена по организационному принципу, т. е. каждая организация, работающая с определенной частью "дерева", желает контролировать и изменять свою часть самостоятельно.
Информация, хранящаяся в определенной зоне, состоит из четырех основных частей:
Вся эта информация хранится в виде RR-записей, т. е. данная зона может быть полностью описана в терминах RR. Зоны могут очень просто перемещаться между серверами имен, например, через механизм перемещения соответствующих RR, посредством обмена RR-сообщениями или передачей по FTP текстовых файлов главного архива.
Информация, находящаяся под управлением данной зоны, состоит из всех RR, прикрепленных ко всем узлам от вершины узла данной зоны к узлам-потомкам зоны.
Для управления зоной особенно важными являются записи RR, описывающие вершину зоны. Эти записи могут быть двух типов: записи серверов имен — по одному в RR и одна запись RR SOA, описывающая параметры работы зоны. Записи NS обозначают срезы данной зоны. Поскольку серверы имен всегда ассоциированы с границами зоны, записи NS RR могут располагаться только в узлах, которые являются родительскими каких-либо зон. Среди записей, образующих зону, записи NS RR могут располагаться как в вершине зоны, так и в ее конце, но никак не посередине.
Примечание
Структура зон содержит всю необходимую информацию для установления соединения с серверами имен своих подзон. Однако для обращения к серверам имен подзон, необходимо знать IP-адреса этих серверов. В частности, если имя сервера имен само хранится в подзоне, мы можем столкнуться с ситуацией, когда запись NS RR говорит, что, для того чтобы получить адрес сервера, нам необходимо обратиться к серверу, адрес которого мы хотим выяснить. Для разрешения подобных недоразумений зона содержит так называемые "приклеенные" записи, которые не являются частью зоны и содержат адреса серверов подзоны.
Одним из предназначений сервера имен является обработка запросов. Существуют два способа обработки запросов сервером:
|
Нерекурсивный способ. Для ответа сервер использует только локальную информацию. Ответное сообщение содержит либо требуемую информацию, либо ошибку, либо ссылку на соседний сервер. Данный способ должен поддерживаться всеми серверами имен. |
|
Рекурсивный способ. В этом состоянии сервер имен работает также в роли программы разрешения (resolve) и в ответном сообщении может возвратить либо ошибку, либо требуемую информацию, но никогда — ссылку на другой сервер имен. Данный способ не обязан поддерживаться серверами имен. Для работы этим способом необходимо специальное программное обеспечение как на хосте сервера имен, так и на машине клиента. Этот способ используется в следующих случаях: |
Алгоритм обработки запросов, используемый сервером имен, зависит от операционной системы хоста и структуры данных, используемой для хранения записей RR. Далее приведен алгоритм, предполагающий, что записи RR организованы в виде структуры дерева, по одному ("дереву") на каждую зону (алгоритм 1).
• Найдена запись QNAME. Если поиск остановился на записи CNAME (псевдонима), но QTYPE не совпадает с CNAME (нам не нужен псевдоним), тогда копируем запись CNAME в сообщение ответа, изменяем QNAME на значение псевдонима CNAME и возвращаемся на шаг 1. Иначе, копируем все записи RR, соответствующие QTYPE в сообщение ответа и переходим на шаг 6.
• Поиск вышел за пределы зоны — мы получаем ссылку. Это случается, когда мы наталкиваемся на запись NS RR, обозначающую срез или конец данной зоны. Копируем запись NS RR в секции полномочий (authority) сообщения ответа, помещаем в дополнительные (additional) секции сообщения адреса соответствующих серверов имен (используя "приклеенные" записи) и переходим на шаг 4.
Алгоритм 1. Обработка запросов сервером имен
• Метка не соответствует записи (метка не существует), проверяем присутствие символа "*". Если символ "*" не обнаружен, проверяем, является ли искомое имя QNAME настоящим или псевдонимом CNAME. Если имя настоящее — возвращаем ошибку поиска. Выходим. Если символ "*" обнаружен, проверяем поле QTYPE. Копируем записи RR в соответствующее QTYPE в сообщение ответа. Переходим на шаг 6.
4. Просматриваем страницы кэша. Если QNAME найдена, копируем все RR с соответствующими QTYPE в сообщение ответа. Переходим на шаг 6.
5. Для ответа на запрос используем локальную программу разрешения имен (или ее копию). Помещаем в сообщении ответа все результаты поиска, включая промежуточные записи CNAME.
6. Используя только локальные данные, добавляем некоторые часто используемые записи RR (например, адреса соответствующих доменов) в дополнительные секции сообщения. Выход.
Одной из обязанностей администратора зон является инсталляция зон на всех серверах имен, которые уполномочены для работы с этими зонами. При изменениях параметров зоны на одном из серверов эти изменения должны быть тиражированы на все серверы имен. Тиражирование или перемещение зон может быть сделано как через FTP, используя механизм передачи текстовых файлов архива, так и через DNS протокол.
Модель автоматического перемещения или обновления зон построена на том, что один из серверов имен является основным (master) в данной зоне. Все изменения на других зависимых (slave) серверах координируются в соответствии с изменениями главных файлов архива основного сервера.
После редактирования файлов главного архива, администратор дает указание серверу загрузить новую зону (или новые параметры зоны). Серверы имен, которые координируют свои данные по данным основного сервера имен, периодически (через определенные промежутки времени) проверяют возможные изменения данных основного сервера и копируют их к себе (в том числе и копию новой зоны).
Для обнаружения изменений зависимые серверы проверяют поле SERIAL записи SOA зоны основного сервера. Какое бы изменение не было сделано, поле SERIAL записи SOA зоны изменится. Оно может или просто увеличиться, или измениться в соответствии с датой и временем изменения файла главного архива (master file). Поле SERIAL служит как бы идентификатором версии настроек зоны, и по его значению можно определить, какая из двух копий зоны более поздняя.
Механизмом периодических запросов зависимых серверов управляют несколько параметров записи RR SOA — REFRESH, RETRY, EXPIRE.
Сразу после загрузки новой зоны, зависимый сервер ждет REFRESH секунд, затем делает проверочный запрос на совпадение серийных номеров зоны данного и основного серверов имен, т. е. поле REFRESH содержит величину интервала в секундах, через который зависимый сервер проверяет совпадение серийных номеров зоны. Если запрос не проходит (возвращается ошибка и др.), запрос будет повторяться через RETRY секунд. Ответом на проверочный запрос является запись RR SOA основного сервера зоны. Если значения полей серийного номера зоны основного и зависимого сервера совпадают, то следующий запрос будет опять сделан через REFRESH секунд. Если зависимый сервер обнаружит, что превышено значение EXPIRY (время существования копии зоны), копия зоны должны быть помечена как устаревшая и уничтожена.
Если ответ на проверочный запрос показал, что зона была изменена, зависимый сервер должен сделать запрос на перемещение зоны (AXFR). Ответом на запрос AXFR будет последовательность сообщений. Первое и последнее сообщения должны содержать данные вершины узла зоны. Между ними должны располагаться сообщения с RR-зоны. Зависимый сервер должен обработать этот поток сообщений и построить собственную копию данной зоны.
Каждый зависимый сервер выполняет операцию синхронизации зон относительно основного сервера, но он также может выполнить эти операции относительно других зависимых серверов. Это может быть использовано, например, при сбоях работы сети и невозможности связаться с основным сервером или сбоях в работе основного сервера.
Программы разрешения имен (resolve) представляют собой интерфейс для работы пользовательских программ с серверами имен домена.
В простейшем случае, программа разрешения получает запрос от пользовательской программы (например, почтового агента, TELNET или FTP) в виде системного вызова или вызова из подпрограммы. Требуемая информация возвращается в формате, понятном пользовательской программе и совместимом с форматом данных локального хоста.
Программы разрешения расположены на той же самой машине, что и программы, запрашивающие этот сервис. Но для работы программ разрешения необходимо обращаться к серверам имен на других хостах, и время ответа этих программ может варьироваться от миллисекунд до нескольких секунд. Поэтому одной из важных особенностей программ разрешения является возможность устранения сетевых задержек ответов, используя механизм кэширования предыдущих результатов запросов. Этот механизм позволяет разделять доступ и совместно использовать кэш данной программы разрешения имен различными процессами, пользователями и хостами сети.
Интерфейс клиентской программы с программой разрешения имен в значительной степени зависит от программного обеспечения локального хоста, но этот интерфейс обязан содержать три стандартные части:
Эти функции возвращают или требуемые данные в определенном формате (записи RR базы данных), или код ошибки (например, имя не зарегистрировано в базе данных), или сообщение, что информация не найдена (например, имя домена существует, но нет данных запрашиваемого типа).
Рассмотрим алгоритм работы программы разрешения имен (алгоритм 2) со следующими исходными параметрами:
|
SNAME — искомый домен |
|
STYPE — QTYPE запроса |
|
SCLASS - QCLASS запроса |
|
SLIST — структура, описывающая серверы имен и зону, которые в данный момент просматривает программа разрешения. Эта структура содержит информацию о серверах имен, которые, предположительно, могут содержать искомые данные. |
|
SBELT — структура, схожая с SLIST. Она инициализируется из файла конфигурации и содержит список серверов, которые должны использоваться, когда программа разрешения имен не имеет никакой информации для выбора сервера имен. |
|
CACHE — эта структура хранит результаты предыдущих запросов. |
Алгоритм 2. Работа программы разрешения имен
Верхний уровень алгоритма запросов содержит четыре шага:
1. Просмотреть информацию на локальном компьютере (как правило, это содержание кэша) и, если информация найдена, вернуть ответ клиенту.
2. Найти сервер, вероятнее всего содержащий ответ на запрос.
3. Отправлять на него запрос до тех пор, пока не придет первый ответ.
4. Проанализировать ответ:
• если ответ содержит всю запрашиваемую информацию или содержит имя ошибки, поместить эти данные в кэш и вернуть клиенту
• если ответ содержит ссылку на другой сервер, поместить эту информацию в кэш и перейти к шагу 2
• если ответ содержит информацию CNAME и не содержит ответа на запрос, поместить информацию CNAME в кэш, изменить SNAME на каноническое имя ресурса из RR CNAME и перейти к шагу 1
• если ответ содержит информацию о том, что запрашиваемые серверы не работают или произошли еще какие-либо сбои в работе, удалить сервер из SLIST и перейти к шагу 3
Рассмотрим эти шаги алгоритма более подробно:
|
На шаге 1 поиск данных производится в кэше компьютера. Если данные находятся в кэше, то считается, что при нормальной работе этого достаточно для формирования ответа. Некоторые программы разрешения можно настроить так, чтобы они не позволяли пользовательским программам использовать кэшированные данные, однако в условиях нормальной работы этого делать не рекомендуется. |
|
На шаге 2 программа разрешения ищет сервер имен, которому можно было бы отправить запрос. Стратегия поиска выглядит так: сначала просматриваются записи RR локального сервера, начиная с SNAME, затем просматриваются серверы-родители SNAME, затем родители этих родителей и т. д. до корня. Например, если SNAME = Mockapetris.ISI.EDU, сначала мы ищем NS записи сервера Mockapetris.ISI.EDU, затем ISI.EDU, затем EDU, и наконец "." (корень). Записи NS RR содержат имена хостов зоны, расположенной рядом или выше SNAME. Копируем этот список в SLIST и, используя локальные данные, определяем адреса этих хостов. |
В некоторых случаях информация адреса недоступна, тогда программа может запустить параллельный процесс программы разрешения имен, который будет пытаться определить адреса по уже известным данным и по мере получения требуемой информации передавать ее программе-родителю. Если поиск записей RR NS завершился неудачно, программа разрешения имен инициализирует SLIST из структуры SBELT, т. е. если программа разрешения не знает, к какому серверу имен ей обращаться, она должна использовать информацию из файла настройки, в котором содержится список "пожарных" серверов. Хотя подобная ситуация относится к исключительным ситуациям, из файла конфигурации, как правило, выбираются какие-либо два сервера из корневых серверов и два сервера из серверов домена. Такой алгоритм построен для увеличения производительности работы системы, поскольку корневые серверы предоставляют быстрый доступ ко всему пространству имен, а локальные серверы имеют более быстрый доступ к сети данного домена,
|
На шаге 3 запросы будут отправляться до тех пор, пока не будет получен какой-либо ответ (организуется периодический опрос по всем адресам серверов). |
|
На шаге 4 производится анализ ответов (синтаксический разбор поступивших данных). Программа должна следить за тем, чтобы ответы содержали метку (идентификатор) сообщения запроса. |
Как правило, на запрос от уполномоченного сервера приходит один ответ, содержащий либо сообщение об ошибке, либо запрашиваемые данные. Данные передаются пользовательской программе и, если поле TTL больше нуля, помещаются в кэш для использования в дальнейшем.
Если ответ содержит сообщение о перенаправлении запроса, программа разрешения должна проверить, что рекомендуемый для обращения сервер "ближе", чем серверы из списка SLIST. Если нет, ответ считается недействительным и отбрасывается. В том случае, если рекомендуемый сервер "ближе", запись RR NS сервера и его адреса кэшируются, записываются в SLIST, и процесс поиска возобновляется.
Если ответ содержит CNAME, а тип запроса не совпадает с CNAME, процесс поиска возобновляется с параметрами ответа (каноническим именем) CNAME.
Рассмотрим пример построения зоны DNS.
На рис.16 уполномоченный сервер каждого домена показан рядом со своим доменом в круглых скобках. Корневые серверы: С.ISI.EDU, SRI-NIC.ARPA и A.ISI.EDU. Домен MIL обслуживают серверы SRI-NIC.ARPA и A.ISI.EDU. Домен EDU обслуживают SRI-NIC.ARPA и C.ISI.EDU.
Примечание
Серверы могут обслуживать как непрерывные, так и разделенные (разрывные) зоны. На данной схеме сервер C.ISI.EDU работает в непрерывной зоне с корневым и EDU доменами. Сервер A.ISI.EDU работает с непрерывной зоной в корневом и MIL доменах, но также обслуживает и разрывную зону ISI.EDU.
Рис. 16. Пример построения зоны с отдельным администрированием корневой зоны и зон MIL, EDU и ISI.EDU
Рассмотрим сервер имен С.ISI.EDU, который обслуживает в классе IN корневой домен, домены MIL и EDU. Данные его зон имеют следующий вид:
IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
870611 ;serial
1800 ;refresh
300 ;retry
604800 ;expiry
86400) ; minimum TTL
NS A.ISI.EDU.
NS C.ISI.EDU.
NS SRI-NIC.ARPA.
MIL. 86400 NS SRI-NIC.ARPA.
86400 NS A.ISI.EDU.
EDU. 86400 NS SRI-NIC.ARPA.
86400 NS C.ISI.EDU.
SRI-NIC.ARPA. A 26.0.0.73
A 10.0.0.51
MX 0 SRI-NIC.ARPA.
HINFO DEC-2060 TOPS20
ACC.ARPA. А 26.6.0.65
HINFO PDP-11/70 UNIX
MX 10 ACC.ARPA.
USC-ISIC.ARPA. CNAME C.ISI.EDU.
73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.
65.0.6.26.IN-ADDR.ARPA. PTR ACC.ARPA.
51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.
52.0.0.10.IN-ADDR.ARPA. PTR C.ISI.EDU.
103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU.
A.ISI.EDU. 86400 A 26.3.0.103
C.ISI.EDU. 86400 A 10.0.0.52
Здесь приведено содержание текстового файла главного архива. Все записи, за исключением записи SOA RR, укладываются в одну строчку. Класс всех записей зоны должен быть один и тот же, поэтому только первая запись зоны SOA RR содержит информацию класса. Далее расположены записи RR NS уполномоченных серверов доменов MIL и EDU, с записями так называемых "приклеенных" адресов (эти записи не являются частью зоны).
К корневому домену присоединены четыре записи RR: SOA, определяющая корневую зону, и три NS RR, которые содержат параметры серверов имен корневой зоны. Данные записи SOA RR описывают управляющие параметры зоны. Данные зоны инсталлированы на хосте SRI-NIC.ARPA, и главную часть зоны составляет домен HOSTMASTER@SRI-NIC.ARPA. Когда сервер имен загружает информацию о зоне, он устанавливает минимальное значение TTL-записей зоны в значение поля MINIMUM (здесь оно равно 86400 секунд или 1 день), это означает, что все управляющие данные зоны не могут иметь значение TTL ниже данного.
Записи NS RR доменов MIL и EDU устанавливают границу между корневой зоной и зонами MIL и EDU.
Примечание
В данном примере нижние (дочерние) зоны обслуживаются серверами имен, которые также обслуживают и корневую зону.
Далее, в качестве еще одного примера, приведена часть файла главного архива зоны EDU:
EDU. IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
870729 ;(serial)
1800 ;(refresh) 30 minutes
300 ;(retry) 5 minutes
604800 ;(expire)
86400 ;(minimum) of a day
)
NS SRI-NIC.ARPA.
NS C.ISI.EDU.
UCI 172800 NS ICS.UCI
172800 NS ROME.UCI
ICS.UCI 172800 A 192.5.19.1
ROME.UCI 172800 A 192.5.19.31
. . .
UDEL.EDU. 172800 NS LOUIE.UDEL.EDU.
172800 NS UMN-REI-UC.ARPA.
LOUIE.UDEL.EDU. 172800 A 10.0.0.96
172800 A 192.5.39.3
. . .
MIT.EDU. 43200 NS XX.LCS.MIT.EDU.
43200 NS ACHILLES.MIT.EDU.
XX.LCS.MIT.EDU. 43200 A 10.0.0.44
ACHILLES.MIT.EDU. 43200 A 18.72.0.8
Запрос QNAME=SRI-NIC.ARPA, QTYPE=A выглядит следующим образом:
|
|
Рис.17. Формат DNS-сообщения запроса и значения полей сообщения
Ответ от сервера имен C.ISI.EDU имеет вид:
|
|
Рис.18. Формат DNS-сообщения запроса и значения полей сообщения ответа
Заголовок (header) сообщения ответа выглядит так же, как и заголовок запроса, за исключением того, что установлен бит RESPONSE (ответ) и бит ЛА (ответ пришел от уполномоченного сервера). Поле Question сообщения ответа выглядит так же, как и поле Question запроса. Поле данных сообщения ответа содержит запрашиваемые адреса.
Если тот же самый запрос пришел бы от другого сервера, который не является уполномоченным сервером домена SRI-NIC.ARPA, ответ выглядел бы гак. как показано на рис. 19.
|
|
Рис.19. Формат DNS-сообщения ответа от неуполномоченного сервера DNS и значения полей сообщения ответа
Заголовок этого сообщения не содержит бита АА и TTL принимает другое значение. Можно предположить, что эти данные получены не из зоны, а из кэша, и время нахождения данных в кэше составляет разницу между значением TTL, установленным в зоне и полученным (8640— 1777). Порядок записей в сообщении ответа RR не имеет значения.
Рассмотрим запрос QNAME=SR1-NIC.ARPA, QTYPE=*. Этот запрос аналогичен предыдущему, только тип возвращаемых данных может принимать различные значения. Тогда от хоста C.ISI.EDU мы получим следующий ответ (рис. 20):
|
|
Рис.20. Формат DNS-сообщения ответа на запрос всех ресурсов, ассоциированных с определённым именем и значением полей сообщения ответа
Если тот же самый запрос будет направлен на сервер имен, который не уполномочен для работы с SRI-NIC.ARPA, ответы будут следующими (рис.21 и 22):
|
|
Рис.21. Формат DNS-сообщения ответа от неуполномоченного сервера имен на запрос всех ресурсов, ассоциированных с определенным именем, и значения полей сообщения ответа
|
|
Рис.22. Формат DNS-сообщения ответа от другого неуполномоченного сервера имен на запрос всех ресурсов, ассоциированных с определенным именем, и значения полей сообщения ответа
Оба ответа не содержат бита АА. Кроме того, эти два сообщения содержат различные значения TTL, а это значит, что оба отвечающих сервера поместили эти данные в кэш в различное время и первый кэшировал ответы с типом QTYPE=A, а второй — с типом HINFO.
Рассмотрим запрос QNAME=SRI-NIC.ARPA, QTYPE=MX. Такой запрос может быть сделан при поиске серверов — маршрутизаторов почты. Ответ сервера C.ISI.EDU будет такой, как показано на рис. 3.23.
Ответ содержит секции MX RR. Кроме того, дополнительные секции пакета содержат информацию об адресах почтовых серверов.
Составим запрос QNAME==SIR-NIC.ARPA, QTYPE=A, в котором пользователь ввел неверное имя домена. Ответ от C.ISI.EDU будет таким, какой показан на рис. 3.24.
Сообщение указывает, что такое имя не существует (выставлен флаг ошибки — RCODE). Запись начала зоны SOA, содержащаяся в поле Authority указывает, что имя домена, указанное в запросе, не существует в данной зоне SOA как минимум 86400 секунд — это срок обновления информации зоны.
|
|
Рис. 23. Формат DNS-сообщения ответа на запрос поиска серверов — маршрутизаторов почты (тип — MX) и значения полей сообщения ответа
|
|
Рис. 24. Формат DNS-сообщения ответа на запрос адреса несуществующего ресурса и значения полей сообщения ответа
Отправим запрос QNAME=BRL.MIL, QTYPE=A на сервер C.ISI.EDU. Ответное сообщение будет иметь вид, показанный на рис. 25.
|
|
Рис. 25. формат DNS-сообщения ответа на запрос адреса ресурса неуполномоченного сервера имен и значения полей сообщения ответа
Поле ответа данного сообщения не содержит информации. Отвечающж сервер С.ISI.EDU не уполномочен для работы с доменом MIL, и он возвра щает информацию об уполномоченных для работы с доменом MIL серверах имен - A.ISI.EDU и SRI-NIC.ARPA.
Следующие примеры иллюстрируют работу программы разрешения имен на компьютере клиента. Предполагаем, что программа разрешения начинает работу без кэша (как бывает после перезагрузки компьютера), хосты системы расположены по адресам 26.х.х.х, и структура SBELT содержит следующую информацию:
match count = -1
SRI-NIC.ARPA. 26.0.0.73 10.0.0.51
A.ISI.EDU. 26.3.0.103
Эта информация определяет серверы, к которым можно обращаться за информацией. Параметр match count = -1 обозначает "удаление" этих серверов (этот параметр играет роль на последующих стадиях алгоритма разрешения).
|
|
Рис. 26. формат DNS-сообщения запроса серверов MX и значения полей сообщения запроса
Предположим, что от SRI-NIC.ARPA получен ответ (рис. 27):
|
|
Рис. 27. Формат DNS-сообщения ответа на запрос серверов MX от неуполномоченного сервера и значения полей сообщения ответа
Программа разрешения кэширует ответ и на его основе строит новый SLIST, который будет выглядеть следующим образом:
match count = 3
A.ISI.EDU. 26.3.0.103
VAXA.ISI.EDU. 10.2.0.27 128.9.0.33
VENERA.ISI.EDU. 10.1.0.52 128.9.0.32
Теперь программа разрешения делает запрос по искомому типу MX. Ответ будет выглядеть примерно так, как показано на рис.28.
После получения ответа, программа разрешения добавляет эту информацию в кэш и возвращает MX RR клиенту.
|
|
Рис. 28. Формат DNS-сообщения ответа на запрос по типу MX и значения полей сообщения ответа
|
|
