Формат сообщения dns

DNS использует протокол транспортного уровня UDP. При этом для DNS запроса и для DNS отклика используется одинаковый формат:

Структура пакета запроса DNS.

Поля запроса имеют следующее назначение.

Значение в поле идентификации (identification) устанавливается клиентом и возвращается сервером. Это поле позволяет клиенту определить, на какой запрос пришел отклик.

Поле флагов предназначено для настройки типа запроса. Назначение битовых полей, начиная с левого, следующее.

QR

opcode

AA

TC

RD

RA

0

rcode

• QR (тип сообщения), 1-битовое поле: 0 обозначает - запрос, 1 обозначает - отклик.

• opcode (код операции), 4-битовое поле со следующими значениями:

0 (стандартный запрос).

1 (инверсный запрос)

2 (запрос статуса сервера).

• AA - 1-битовый флаг, который означает "авторитетный ответ" (authoritative answer). Сервер DNS имеет полномочия для этого домена в разделе вопросов.

• TC - 1-битовое поле, которое означает "обрезано" (truncated). В случае UDP это означает, что полный размер отклика превысил 512 байт, однако были возвращены только первые 512 байт отклика.

• RD - 1-битовое поле, которое означает "требуется рекурсия" (recursion desired). Бит может быть установлен в запросе и затем возвращен в отклике. Этот флаг требует от DNS сервера обработать этот запрос самому (т.е. сервер должен сам определить требуемый IP адрес, а не возвращать адрес другого DNS сервера), что называется рекурсивным запросом (recursive query). Если этот бит не установлен и запрашиваемый сервер DNS не имеет авторитетного ответа, запрашиваемый сервер возвратит список других серверов DNS, к которым необходимо обратиться, чтобы получить ответ. Это называется повторяющимся запросом (iterative query) .

• RA - 1-битовое поле, которое означает "рекурсия возможна" (recursion available). Этот бит устанавливается в 1 в отклике, если сервер поддерживает рекурсию.

• Это 3-битовое поле должно быть равно 0.

• rcode это 4-битовое поле кода возврата. Обычные значения: 0 (нет ошибок) и 3 (ошибка имени- имени не существует на сервер домена).

Формат каждого вопроса в разделе вопросов (question) следующий: имя вопроса, тип вопроса/отклика, класс вопроса:

Имя запроса (query name) - это искомое имя. Оно выглядит как последовательность из одного или нескольких слов. Каждое слово начинается с 1-байтового счетчика, который содержит количество следующих за ним букв слова. Имя заканчивается байтом равным 0, который является словом с нулевой длиной и обозначает корень. Каждый счетчик байтов должен быть в диапазоне от 0 до 63, так как длина слова ограничена 63 байтами.

Каждый вопрос имеет тип запроса, каждый отклик содержит запись ресурса определенного типа.

Протокол работает с вопросами нескольких классов. Вопрос о IP адресе только один из вариантов:

Типы запросов
Имя	Цифровое значение	Описание
A	1	IP адрес
NS	2	сервер DNS
CNAME	5	каноническое имя
PTR	12	запись указателя
HINFO	13	информация о хосте
MX	15	запись об обмене почтой
AXFR	252	запрос на передачу зоны
* или ANY	255	запрос всех записей

Разрешение имен. Кроме основной своей функции разрешения доменного имени хоста в его IP-адрес, протокол DNS обеспечивает и обратное разрешение IP-адреса в доменное имя при помощи подзон реверсивной зоны in_addr.arpa.

Структура базы данных DNS.

Записи ресурсов, из которых составлена база DNS, разделяются по функциональным типам. Приведем некоторые из типов.

Тип	Описание
A	IP-адрес
PTR	Указатель реверсивной зоны
CNAME	Каноническое имя (псевдоним)
MX	Записи для серверов электронной почты
NS	Сервер имен домена

Когда в домене присутствует вторичный сервер DNS, на него периодически дублируется вся эта информация (передача зоны). Для передачи зоны используется транспорт TCP.

Протокол SMTP

Появление масштабных территориально распределенных сетей не могло не подвигнуть пользователей на обмен текстовыми сообщениями. Изначально это была просто пересылка файлов, потом появились первые примитивные протоколы, работавшие с текстовыми файлами, включавшими адрес получателя. Но требования пользователей росли, им хотелось иметь возможность посылать сообщение не одному, а сразу целой группе получателей, получать уведомления о доставке, иметь удобный интерфейс для работы с почтой, иметь возможность пересылать не только текст, но и другие форматы данных.

Для обеспечения этих потребностей был разработан SMTP (Simple Mail Transfer Protocol) - простой почтовый протокол, описанный в RFC 821 [Postel 1982]. Формат сообщения электронной почты, которое передается между двумя MTA в соответствии с RFC 821 определяется в RFC 822 [Crocker 1982].

SMTP обеспечивает передачу почтовых сообщений между системами и уведомления о входящей почте. Обмен почтой с использованием TCP осуществляется посредством агентов передачи сообщений (MTA - message transfer agent). Пользователи обычно не общаются с MTA. Протокол определяет, как два MTA обмениваются сообщениями по TCP соединению.

При общении между двумя MTA используется NVT ASCII. Клиент подключается на порт 25 сервера, используя протокол telnet. Команды посылаются клиентом серверу, а сервер отвечает с помощью цифровых кодов и опциональных текстовых строк.

Команды SMTP представляют собой сообщения ASCII, передаваемые между хостами SMTP. Ниже приведен список поддерживаемых команд:

Команда	Описание
DATA	Начинает сборку (composition) сообщения.
EXPN<string>	Возвращает имена из указанного списка рассылок.
HELO <domain>	Возвращает идентификацию почтового сервера.
HELP <command>	Возвращает информацию об указанной команду.
MAIL FROM <host>	Инициирует почтовый сеанс с хоста.
NOOP	Нет операций кроме подтверждений от сервера.
QUIT	Прерывает почтовую сессию.
RCPT TO <user>	Обозначает получателя почты.
RSET	Сбрасывает (Reset) почтовое соединение.
SAML FROM <host>	Передает почту на терминал пользователя и в почтовый ящик.
SEND FROM <host>	Передает почту на терминал пользователя.
SOML FROM <host>	Передает почту на терминал пользователя или в почтовый ящик.
TURN	Меняет ролями отправителя и получателя.
VRFY <user>	Проверяет идентификацию пользователя.

Электронное сообщение состоит из трех частей.

Конверт используется MTA для доставки. Конверт может быть определен двумя SMTP командами:

MAIL From jen@mail.sgu.ru- отправитель

RCPT To nil@mail.ru- получатель

Заголовки используются пользовательскими агентами. Могут использоваться заголовки полей: Received, Message-Id, From, Date, Reply-To, To, Subject. Каждое поле заголовка содержит имя, после которого следует двоеточие, а затем следует значение этого поля. RFC 822 определяет формат и интерпретацию полей заголовка. Длинные поля заголовков могут быть разбиты на несколько строк, причем дополнительные строки начинаются с пробела.

Тело - это содержимое сообщения от отправителя к получателю. RFC 822 определяет тело сообщения как текстовые строки в формате NVT ASCII. Когда происходит передача содержимого с использованием команды DATA, заголовки передаются первыми, за ними следует пустая строка и затем следует тело сообщения. Каждая строка, передаваемая с использованием команды DATA, ограничена в длину 1000 байт.

Доставка сообщений происходит по следующей схеме. Пользовательский агент передает сообщение своему MTA. Агент по доменному имени в адресе получателя должен найти почтовый сервер MTA получателя. Для этого используются DNS-запросы типа MX, возвращающие для MTA отправителя доменное имя и адрес сервера, уполномоченного получать сообщения для домена получателя. RFC 974 [Partridge 1986] описывает, как MTA обрабатывает записи MX. После этого MTA отправителя, выступая в качестве клиента, устанавливает telnet - соединение на 25 порт найденного сервера и передает ему сообщение. Если сервер, получивший сообщение, является сервером получателя, в этом случае получатель содержится в его базе абонентов. Сообщение записывается в почтовый файл абонента. Если сервер является сервером пересылки, процедура MX-запроса повторяется и сообщение передается по цепочке, пока не будет доставлено.

Для чтения сообщений в почтовом файле сервера абонент может использовать локальную утилиту почтового клиента или пользоваться удаленным доступом к почтовым файлам по протоколам POP3 или IMAP.