DNS запити

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

Для DNS запроса и для DNS отклика используется одинаковый формат. На рисунке 2 показан общий формат DNS сообщения.

Рис.2. Общий формат DNS запроса и ответа.

Сообщение содержит фиксированный 12-байтный заголовок, за которым следуют четыре поля переменной длины.

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

16-битовое поле флагов (flags) поделено на несколько частей, как показано на рисунке 3.

Рис.3. Поле флагов (flags) в заголовке DNS.

Описание каждого поля мы начнем с крайне левых битов. 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 в отклике, если сервер поддерживает рекурсию. Мы увидим в наших примерах, что большинство серверов DNS поддерживают рекурсию, за исключением нескольких корневых серверов (коневые сервера не в состоянии обрабатывать рекурсивные запросы из-за своей загруженности). Это 3-битовое поле должно быть равно 0. rcode это 4-битовое поле кода возврата. Обычные значения: 0 (нет ошибок) и 3 (ошибка имени). Ошибка имени возвращается только от полномочного сервера DNS и означает, что имя домена, указанного в запросе, не существует.

Следующие четыре 16-битных поля указывают на количество пунктов в четырех полях переменной длины, которые завершают запись. В запросе количество вопросов (number of questions) обычно равно 1, а остальные три счетчика равны 0. В отклике количество ответов (number of answers) по меньшей мере равно 1, а оставшиеся два счетчика могут быть как нулевыми, так и ненулевыми.

Раздел вопросов в DNS запросе

Формат каждого вопроса в разделе вопросов (question) показан на рисунке 4. Обычно присутствует только один вопрос.

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

Рис. 4. Формат раздела вопроса (question) в запросе DNS.

(Дальше в этом разделе мы увидим, что байт счетчик с двумя старшими битами, установленными в 1, значения от 192 до 255, используется в схеме со сжатием.) В отличие от многих других форматов сообщений, которые мы рассмотрели, этому полю разрешено заканчиваться на ограничителе не равном 32 битам. Заполнение не используется.

На рисунке 5 показано, как хранится имя домена gemini.tuc.noao.edu.

Рис.5. Представление имени домена gemini.tuc.noao.edu.

У каждого вопроса есть тип запроса (query type), а каждый отклик (называемый записью ресурса, о чем мы поговорим ниже) имеет тип (type). Существует около 20 различных значений, некоторые из которых в настоящее время уже устарели. В таблице 2 показаны некоторые из этих значений. Тип запроса это надмножество (множество, подмножеством которого является данное множество) типов: два из показанных значений, могут быть использованы только в вопросах.

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

• или ANY

255 запрос всех записей ·

Наиболее распространенный тип запроса - тип A, который обозначает, что необходим IP адрес для запрашиваемого имени (query name). PTR запрос требует имена, соответствующие IP адресу. Это запрос указателя, который мы опишем в разделе "Запросы указателя" этой главы. Другие типы запросов мы опишем в разделе "Записи ресурсов"

Класс запроса (query class) обычно равен 1, что указывает на адреса Internet. (В некоторых случаях поддерживаются не-IP значения.)

Часть записи ресурса в отклике DNS

Последние три поля в DNS сообщении это ответы (answers), полномочия (authority) и дополнительная информация (additional information), общий формат называется записью ресурса (RR - resource record). На рисунке 6 показан формат записи ресурса.

Рис.6. Формат записи ресурса DNS.

Имя домена (domain name) это имя, которому соответствуют следующие данные ресурса. Формат имени домена тот же, что мы описали ранее для поля имени запроса (query name) (рисунок 5).

Тип (type) указывает на один из типов кодов RR. Это то же самое, что и значения типа запроса (query type), которые мы описали раньше. Для данных Internet класс (class) обычно установлен в 1.

Поле время жизни (time-to-live) это количество секунд, в течение которых RR может быть кэширована клиентом. Обычно TTL RR равно 2 дням.

Длина записи ресурса (resource data length) указывает на количество данных ресурса (resource data). Формат этих данных зависит от типа (type). Для типа равного 1 (запись A) данные ресурса - это 4-байтный IP адрес. Сейчас мы описали основной формат DNS запросов и откликов. Запросы указателя

Для понимания работы DNS важно знать, как обрабатываются запросы указателя - задан IP адрес, возвращается имя (или имена), соответствующее этому адресу.

Во-первых, вернемся к рисунку 1 и рассмотрим домен верхнего уровня arpa, а также домен in-addr, находящийся ниже. Когда организация вступает в Internet и получает часть простраства имен DNS, как, например, noao.edu, она также получает право на часть пространства имен in-addr.arpa, соответствующее ее IP адресам в Internet. В данном случае noao.edu - это сеть класса B с идентификатором 140.252. Уровень дерева DNS ниже in-addr.arpa должен быть первым байтом IP адреса (140 в данном примере), следующий уровень это следующий байт IP адреса (252), и так далее. Однако помните, что имена пишутся, снизу-вверх по дереву DNS. Это означает, что DNS имя хоста sun с IP адресом 140.252.13.33 будет 33.13.252.140.in-addr.arpa.

Мы должны написать 4 байта IP адреса задом наперед, потому что полномочия делегируются на основе идентификаторов сетей: первый байт адрес класса A, первый и второй байты адреса класса B, а первый, второй и третий байты это адреса класса C. Первый байт IP адреса должен быть непосредственно под меткой in-addr, однако полные имена доменов (FQDN) пишутся снизу вверх по дереву. Если бы FQDN писались сверху вниз, DNS имя для IP адреса было бы arpa.in-addr.140.252.13.33, однако в этом случае FQDN для хоста должно быть edu.noao.tuc.sun.

Без отдельных ветвей дерева DNS осуществить преобразования адрес - имя, (обратное преобразование) можно было бы только начиная от корня дерева и просматривая каждый домен верхнего уровня. При сегодняшнем размере Internet это могло бы занять дни или даже недели. Использование же in-addr.arpa приемлемый вариант, несмотря на переставленные местами байты в IP адресе и специальные домены, иногда вносящие определенную путаницу.

Однако встретиться с доменом in-addr.arpa и переставленными байтами в IP адресе можно только тогда, когда мы общаемся с DNS непосредственно, используя, такие программы как host или просматривая пакеты с использованием tcpdump. При работе приложения, разборщик (gethostbyaddr) обычно воспринимает IP адрес и возвращает информацию о хосте. Перестановка байтов и добавление домена in-addr.arpa осуществляется разборщиком автоматически. Записи ресурсов

Всего существует около 20 различных типов записей ресурсов, некоторые из которых мы сейчас опишем.

А Запись А определяет IP адрес. Хранится как 32-битное двоичное значение.

PTR Запись указателя используется для запросов указателя. IP адрес представляется в виде имени домена (последовательность меток) в домене in-addr.arpa.

CNAME "Каноническое имя" (canonical name). Представляется как имя домена (последовательность меток). Имя домена, которое имеет каноническое имя, часто называется псевдонимом (alias). Они используются некоторыми FTP узлами, для того чтобы предоставить легкозапоминаемый псевдоним для какой-либо системы.

Например, сервер gated доступен через анонимное FTP с сервера gated.cornell.edu. Однако, не существует системы, названной gated, это псевдоним для какой-то другой системы. Эта другая система является каноническим именем для gated.cornell.edu:

sun % host -t cname gated.cornell.edu gated.cornell.edu CNAME COMET.CIT.CORNELL.EDU

Здесь мы использовали опцию -t, чтобы указать на один конкретный тип запроса.

HINFO Информация о хосте: две символьные строки, указывающие на центральный процессор (CPU) и операционную систему. Не все хосты предоставляют записи HINFO для своих систем, и предоставляемая информация может быть устаревшей.

sun % host -t hinfo sun sun.tuc.noao.edu HINFO Sun-4/25 Sun4.1.3

MX Записи, посвященные обмену почтой, которые используются по следующему сценарию: (1) узел, который не подсоединен к Internet, может использовать узел, который подсоединен к Internet, в качестве своего почтового сервера. Два узла работают попеременно, обмениваясь любой прибывшей почтой, в основном с использованием протокола UUCP. (2) запись MX предоставляет возможность доставить почту на альтернативный хост, когда хост назначения недоступен. (3) записи MX позволяют организациям предоставлять виртуальные хосты, на которые можно отправлять почту, как, например, cs.university.edu, даже если хост с таким именем не существует. (4) Организации со шлюзами firewall могут использовать записи MX, чтобы ограничить доступ к внутренним системам.

Многие хосты, которые не подключены к Internet, имеют UUCP каналы к хостам, подключеным к Internet, как, например, UUNET. С помощью записи MX обеспечивается передача электронной почты с использованием стандартного обращения user@host (пользователь@хост). Например, фиктивный домен foo.com может иметь следующую MX запись:

sun % host -t mx foo.com foo.com MX relay1.UU.NET foo.com MX relay2.UU.NET

MX записи используются программами доставки почты на хостах, подключенных к Internet. В этом примере программа доставки почты говорит "если у тебя есть почта, которую необходимо послать на [email protected], пошли почту на relay1.uu.net или на relay2.uu.net".

В каждой записи MX есть 16-битное целое значение, которое называется значением предпочтительности. Если для одного пункта назначения существует несколько MX записей, они будут использованы по порядку, начиная с той записи, у которой наименьшее значение предпочтительности.

Записи MX используются, когда хост выключен или недоступен. В этом случае программа доставки почты использует MX записи только в том случае, если не может подсоединиться к пункту назначения с использованием TCP. Для объединенных сетей, с которыми экспериментировал автор, его основная система подключена к Internet через SLIP канал, и если она не работает, мы получим:

sun % host -tv mx sun Query about sun for record types MX Trying sun within tuc.noao.edu ... Query done, 2 answers,authoritative status: no error sun.tuc.noao.edu 86400 IN MX 0 sun.tuc.noao.edu sun.tuc.noao.edu 86400 IN MX 10 noao.edu

Опцию -v позволяет посмотреть значения предпочтительности. (Благодаря этой опции в выводе появятся и все другие поля.) Второе поле, 86400, - это время жизни в секундах. Время жизни равно 24 часам (24х60х60). Третья колонка, IN, это класс (Internet). Мы видим, что непосредственная доставка на хост (первая запись MX) имеет наименьшее значение предпочтительности равное 0. Если это не работает (SLIP канал выключен), используется следующее более высокое значение предпочтительности (10), и делается попытка доставить почту на хост noao.edu. Если и это не сработает, отправитель отработает тайм-аут и повторит попытки позже.

NS Запись имени сервера. Указывает на полномочные DNS серверы для домена. Представлена в виде имен доменов (последовательность меток). Мы рассмотрим примеры этих записей в следующем разделе.

Это общие типы RR.

Протокол DNS для роботи використовує 53-й TCP-або UDP-порт для відповідей на запити. Традиційно запити і відповіді відправляються у вигляді однієї UDP датаграми. TCP використовується для AXFR-запитів.

Прямий запит

Прямий запит (forward) — запит на перетворення доменне ім'я (символьної адреси) хоста в числову IP-адресу.

Зворотний запит

Зворотний запит (reverse) — запит на перетворення IP-адреси в ім'я хоста.

DNS використовується в першу чергу для перетворення символьних імен в IP-адреси, але він також може виконувати зворотний процес. Для цього використовуються вже наявні кошти DNS. Справа в тому, що із записом DNS можуть бути зіставлені різні дані, в тому числі і будь-яке символьне ім'я. Існує спеціальний домен in-addr.arpa, записи в якому використовуються для перетворення IP-адрес в символьні імена.

Наприклад, для отримання DNS-імені для адреси 11.22.33.44 потрібно запросити у DNS-сервера запис 44.33.22.11.in-addr.arpa, і той поверне відповідне символьне ім'я. Зворотний порядок запису частин IP-адреси пояснюється тим, що в IP-адресах старші біти розташовані на початку, а в символьних DNS-іменах старші (що знаходяться ближче до кореня) частини розташовані в кінці.

Рекурсивний запит

Рекурсивний запит передбачає отримання остаточної відповіді від сервера, до якого він спрямований. Рекурсію виконує сервер.

Ітеративний запит

Ітеративний запит - припускає (допускає) виконання рекурсії клієнтом.