Мельников Д. А. - Организация и обеспечение безопасности информационно-технологических сетей и систем - 2012

На рис. 18.20 представлен формат субполя «SOA» (the start of а zone of authority - начало зоны ответственности) в поле «RDATA». Субполе «SOА» включает следующие элементы (рис. 18.20):

Рис. 18.20. Формат субполя «SOA» в поле «RDATA»

о«MNAME» представляет собой DNS-имя (<domain-name>) DNS-сервера, который был оригинальным или первичным ис­ точником данных для этой зоны;

в«RNAME» - DNS-имя (<domain-name>), которое определяет почтовый сервер (почтовый адрес) лица, которое отвечает за эту зону;

о«SERIAL» - 32-битовое число без знака, которое определяет номер версии оригинальной копии зоны. При каких-либо зо­ нальных процедурах информационного обмена значение это­ го числа сохраняется. Это число преобразуется в десятичное и при его сравнении должна использоваться простая арифмети­ ческая процедура;

°«REFRESH» - 32-битовый временной интервал, не позднее ко­ торого зональная БД должна быть обновлена;

0«RETRY» - 32-битовый временной интервал, который должен пройти, прежде чем провести новую попытку обновления данных, если предшествующая попытка закончилась неудачно (аналог «тайм-аута»);

e«EXPIRE» - 32-битовый временной интервал, устанавливаю­ щий верхний предел, который должен пройти перед тем, как зона потеряет ранг «авторизованной зоны»;

о«MINIMUM» - 32-битовое число без знака, определяющее ми­ нимальное значение в поле «TTL», которое должно быть на­ правлено вместе с любой RR-записью из этой зоны.

Записи «SOA» не влекут за собой каких-либо дополнительных процедур обработки. Все временные параметры измеряются в се­ кундах.

Большинство из этих полей имеют отношение только к проце­ дурам обслуживания DNS-сервера. Однако, элемент «MINIMUM» используется во всех процедурах запроса, в ответ на которые пере­ даются зональные RR-записи. Всякий раз, когда RR-запись передает­ ся в качестве ответа на запрос, поле «TTL» имеет следующие значе­ ния: максимальное значение извлекается из RR-записи, а мини­ мальное значение - из субполя «SOА» («MINIMUM»). Таким обра­ зом, значение «MINIMUM» из субполя «SOА» определяет нижнюю границу «TTL» для RR-записей в зоне.

На рис. 18.21 представлен формат субполя «ТХТ» (text) в поле «RDATA».

1

TXT-DATA

Рис. 18.21. Формат субполя «ТХТ» в поле «RDATA»

«TXT-DATA» (рис. 18.21) представляет собой одну или более <сЬагаиег-5Ы^>-последовательностей.

Рис. 18.22. Формат поля «RDATA» для Internet

Записи «TXT-DATA» используются для размещения в них ка­ кого-либо описания в текстовой форме. Семантика текста зависит от сегмента/области, в которой он создан.

Специальные RR-записи для Internet-сети. На рис. 18.22 представлен формат поля «RDATA». «ADDRESS» (рис. 18.22) пред­ ставляет собой 32-битовый 1Ру4-адрес. IP-узлы, которые имеют не­ сколько IP-адресов, будут иметь несколько RR-записей типа «А».

Записи «А» не влекут за собой каких-либо дополнительных процедур обработки. Поле «RDATA» RR-записи типа «А» в мастерфайле представляет собой IP-адрес Internet в форме четырех десяти­

В зависимости от типа DNS-сообщения (рис. 18.24) некоторые поля в нем могут быть пустыми, за исключением заголовка - по­ следний присутствует всегда. Собственно говоря, именно заголовок определяет, какие поля DNS-сообщения будут в нем представлены, и сам тип сообщения - запрос или ответ (стандартный или специа­ лизированный запрос и др.).

ПОЛЯ СО О БЩ ЕН И Я | С О Д Е Р Ж А Н И Е П О Л Е Й

Header (заголовок) |Определяет тип DNS-сообщения

Question (вопрос) |Вопрос к DNS-cepeepy

Answer (ответ) |RR-записи, отвечающие на поставленный вопрос

Authority (авторизация) |RR-записи, указывающие на авторизованный сервер

Additional (дополнение) | RR-записи, содержащие дополнительную информацию

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

Имена, содержащиеся в полях после заголовка, указывают на свое предыдущее использование в стандартных запросах. Поле «Question» состоит из субполей, которые определяют сущность во­ проса, направленного на DNS-сервер. К этим субполям относятся: «запрашиваемый тип записи» (QTYPE), «запрашиваемый класс за­ писи» (QCLASS) и запрашиваемое DNS-имя (QNAME). Последние три поля имеют одинаковый формат и могут быть пустыми (без RRзаписей). Поле «Answer» содержит записи, которые являются отве­ том на отправленный запрос. Поле «Authority» содержит записи, которые указывают направление на авторизованный DNS-сервер. Поле «Additional» содержит записи, которые связаны с запросом, но не являются прямыми ответами на вопрос.

Рис. 18.25. Формат заголовка (поле «Header») DNS-сообщения

На рис. 18.25 представлен формат заголовка DNS-сообщения. Субполя заголовка имеют следующее предназначение:

о«ID» (Identifier) - 16-битовый идентификатор, устанавливае­ мый программным модулем, который сформировал данный тип запроса. Этот идентификатор копируется в соответствую­ щее ответное DNS-сообщение и может быть использован за­

прашиваемой стороной для сравнения ответов на невыпол­ ненные запросы;

о«QR» (Query/Response) - однобитовое субполе, которое опре­ деляет тип DNS-сообщения: «О» - запрос; «1» - ответ;

о«OPCODE» (Option Code) - 4-битовое субполе, которое опреде­ ляет тип запроса в данном DNS-сообщении. Это значение ус­ танавливается отправителем запроса и копируется в ответном сообщении. Кодирование этого субполя следующее:

-«О» - стандартный запрос (QUERY);

-«1» - встречный запрос (IQUERY);

-«2» - запрос состояния сервера (STATUS);

-«3... 15» - зарезервировано для дальнейшего применения;

©«АА» (Authoritative Answer) - однобитовое субполе, которое используется только в ответных сообщениях (устанавливается в «1») и определяет, что отвечающий DNS-сервер является ав­ торизованным для DNS-имени, указанного в поле «Question». (П римечание. Содержание поля «Answer» может включать не­ сколько DNS-имен владельца записи, так как он может иметь несколько псевдонимов. Бит «АА» указывает на имя, которое будет сравниваться с именем, указанным в запросе, или на первое имя владельца записи в поле «Answer».);

о«ТС» (Truncation) - однобитовое субполе, которое определяет, что DNS-сообщение было сокращено («урезано») вследствие того, что длина сообщения превышает максимально разре­ шенный размер, установленный для передачи;

о«RD» (Recursion Desired) - однобитовое субполе, которое ука­ зывает на наличие запроса в режиме рекурсии (рекурсивный режим обслуживания). Этот бит может быть установлен в «1» в запросах и копируется в ответных сообщениях. Если бит «RD» установлен, то он предписывает DNS-серверу обслуживать за­ прос рекурсивно. Рекурсивный режим обслуживания является не основным (дополнительным) режимом;

•«RA» (Recursion Available) - однобитовое субполе, которое ука­ зывает на возможность рекурсивного режима обслуживания со стороны DNS-сервера, если этот бит установлен в «1». Этот бит может копироваться, а может и не копироваться в ответах;

e«Z» - это субполе зарезервировано для будущего использова­ ния. Оно всегда должно быть заполнено нулями (и в запросах, и в ответах);

•«RCODE» (Response Code) - 4-битовое поле, которое является частью ответных DNS-сообщений. Кодирование этого субполя следующее:

- «О» - отсутствие ошибок;

-«1» - ошибка в формате сообщения. DNS-сервер не спосо­ бен распознать запрос;

-«2» - DNS-сервер неисправен. Он не смог обработать посту­ пивший запрос вследствие собственных внутренних причин;

-«3» - ошибочное DNS-имя. Имеет отношение только к отве­ там авторизованных DNS-серверов. DNS-имя, представлен­ ное в запросе, не существует;

-«4» - не обслуживается. DNS-сервер не обслуживает (не об­ рабатывает) такой тип запросов;

15\

L E N G T H

Q N A M E

Q T Y P E

Q C L A S S

Рис. 18.26. Формат поля «Question» DNS-сообщения

-«5» - отказ. DNS-сервер отказался от обработки запроса (проведения специфической процедуры) по соображениям безопасности. Например, DNS-сервер не желает обеспечи­ вать информацией соответствующую запрашивающую сто­ рону или не желает проводить соответствующую обработку с поступившими данными (например, при внутри зональ­ ном информационном обмене);

-«6... 15» - зарезервировано для дальнейшего применения;

в«QDCOUNT» - 16-битовое число без знака, которое определяет объем данных в поле «Question»;

о«ANCOUNT» - 16-битовое число без знака, которое определяет количество RR-записей в поле «Answer»;

о«NSCOUNT» - 16-битовое число без знака, которое определяет количество RR-записей об авторизованном DNS-сервере в поле «Authority»;

« «ARCOUNT» - 16-бито'вое число без знака, которое определяет количество RR-записей в поле «Additional».

Поле «Question» DNS-сообщения используется для доставки «вопроса» в большинстве сообщений-запросов, то есть для доставки параметров, которые определяют существо вопроса. С уб п ол е «QDCOUNT» определяет количество записей в поле «Question» (как правило, одна), каждая из которых имеет формат, представленный на рис. 18.26.

Рис. 18.27. Формат полей «Answer», «Authority» и «Additional» DNS-сообщения

Субполя в поле «Question» имеют следующее предназначение:

о«QNAME» - DNS-имя, представленное в форме последователь­ ности маркеров, где каждый маркер состоит из одиночного ок­ тета («Length»), указывающего на размер маркера в октетах, и октетов, которые содержат сам маркер. DNS-имя заканчивается нулевым октетом, что означает нулевой маркер корневого узла. (.Примечание. Это поле может содержать нечетное число окте­ тов, однако, процедура дополнения не используется.);

о«QTYPE» - двухоктетный код, который определяет тип запро­ са. Величины в этом поле включают все коды, которые допус­ тимы для поля «ТУРЕ» в RR-записях;

в«QCLASS» - двухоктетный код, который определяет класс за­ проса. Например, значение «IN» в этом поле указывает на

Internet.

Поля «Answer», «Authority» и «Additional» DNS-сообщения

имеют одинаковый формат (рис. 18.27), а вот их размеры определя­ ются соответствующими субполями «ANCOUNT», «NSCOUNT» и «ARCOUNT» заголовка DNS-сообщения.

Субполя в полях «Answer», «Authority» и «Additional» имеют следующее предназначение:

о «NAME» - DNS-имя того, кому принадлежит эта запись;

в«ТУРЕ» - двухоктетное субполе, в котором размещается один из кодов, определяющих тип RR-записи. Это поле определяет сущность данных, размещенных в субполе «RDATA»;

•«CLASS» - двухоктетное субполе, которое определяет класс данных, размещенных в субполе «RDATA»;

•«TTL» - 32-битовое число без знака (секунды), определяющее временной интервал, в течение которого RR-запись может хра­ ниться в кэш-памяти до того как она будет уничтожена. Нулевое

значение в этом субполе означает то, что данная запись может быть использована только в течение процедуры информацион­ ного обмена, а ее хранение в кэш-памяти не целесообразно;

в«RDLENGTH» - 16-битовое число без знака, которое определя­ ет размер субполя «RDATA» в октетах;

в«RDATA» - различной длины последовательность октетов, ко­ торая отражает информационный ресурс. Формат этой ин­ формации может быть различным и зависит от типа и класса записи. Например, если тип записи «А», а класс записи «IN», то тогда поле «RDATA» содержит 4-октетный IP-адрес в Internet.

Сжатие (компрессия) DNS-сообщений. В целях уменьшения размера DNS-сообщения, в DNS-системе используется процедура компрессии, которая исключает повторение DNS-имен в сообще­ нии. В этой процедуре полное DNS-имя или перечень маркеров в конце DNS-имени заменяются указателем («pointer») на прежнее ме­ стонахождение такого же DNS-имени.

15\

Рис. 18.28. Формат указателя в DNS-сообщении

Формат указателя представлен на рис. 18.28. Первые два бита указателя устанавливаются в «1». Они позволяют отличать указатель от маркера, так как маркер должен начинаться с двух первых нуле­ вых битов, потому что маркеры ограничены 63-октетным размером или меньшим. (Значения первых двух битов - «10» и «01» - зарезер­ вированы для будущего использования.) Поле «OFFSET» (смещение) указателя определяет смещение от начала сообщения (то есть пер­ вый октет субполя «ГО» в заголовке («Header») сообщения). Если по­ ле «OFFSET» содержит нулевое значение, то тогда первый октет субполя «ГО» в заголовке является первым в сообщении.

Процедура компрессии позволяет представить DNS-имя в со­ общении в одной из следующих форм:

окак последовательность маркеров, заканчивающуюся нулевым октетом;

ов форме указателя;

окак последовательность маркеров, заканчивающуюся указателем.

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

18.6. Мастер-файлы

Мастер-файлы представляют собой текстовые файлы, которые содержат RR-записи в текстовой форме. Так как содержание зоны может быть представлено в форме перечня RR-записей, мастерфайл очень часто используется для определения зоны, хотя он мо­ жет быть использован для перечня компонентов, хранящихся в кэш­ памяти.

Формат таких файлов представляет собой последовательность записей (строк). Эти записи являются преимущественно линейно­ ориентированными (строчная форма), хотя для продолжения пе­ речня элементов, выходящих за линейную границу, могут быть ис­ пользованы обычные круглые скобки. Более того, текстовые кон­ станты могут включать символ «CRLF» («перевод каретки - новая строка»), то есть внутри текста. Любая комбинация символов «табу­ ляция» и «пробел» выступает в роли разделителя между элемента­ ми, которые входят в состав записи. В конце любой строки (линии) мастер-файла может размещаться комментарий. Комментарий на­ чинается после разделительного символа «;» (точка с запятой).

Далее приводится пример записи в мастер-файле:

Пустые строки (<blank>), с комментариями или без, допуска­ ются в любых местах мастер-файла.

В мастер-файлах различают две управляющие строки:

•«$ORIGIN» (источник) следует перед DNS-именем, и переус­ танавливает все DNS-имена соответствующих владельцев в од­ но имя установленного владельца;

о«$INCLUDE» (вставка) размещает файл с именем в текущий файл, и может, дополнительно, определять DNS-имя установ­ ленного владельца для включенного файла. Эта строка также может иметь комментарий. (Примечание. Строка «$INCLUDE» никогда не изменяет соответствующий источник «родительско­ го файла», не обращая внимания на изменения, которые делает соответствующий источник внутри включенного файла.)

Последние две строки представляют собой RR-записи. Если стро­

ка для RR-записи начинается с пустой строки, то тогда RR-запись при­ надлежит последнему установленному владельцу. Если же строка для RR-записи начинается с <domain-name> (с DNS-имени), то тогда имя владельца переустановлено.