Відмінності між версіями «DNS запити»

Матеріал з Вікі ЦДУ
Перейти до: навігація, пошук
 
(не показано 3 проміжні версії ще одного учасника)
Рядок 1: Рядок 1:
Формат сообщения DNS
+
===Формат повідомлень DNS===
  
 +
Для DNS запиту і для DNS відгуку використовується однаковий формат. На малюнку показаний загальний формат DNS повідомлення.
  
Для DNS запроса и для DNS отклика используется одинаковый формат. На рисунке 2 показан общий формат DNS сообщения.
 
  
  
 +
===Загальний формат DNS запиту і відповіді.===
  
Рис.2. Общий формат DNS запроса и ответа.
+
Повідомлення містить фіксований 12-байтний заголовок, за яким слідують чотири поля змінної довжини.
  
Сообщение содержит фиксированный 12-байтный заголовок, за которым следуют четыре поля переменной длины.  
+
Значення в полі ідентифікації (identification) встановлюється клієнтом і повертається сервером. Це поле дозволяє клієнту визначити, на який запит прийшов відгук.
  
Значение в поле идентификации (identification) устанавливается клиентом и возвращается сервером. Это поле позволяет клиенту определить, на какой запрос пришел отклик.
+
16-бітове поле прапорів (flags) поділено на кілька частин, як показано на малюнку
  
16-битовое поле флагов (flags) поделено на несколько частей, как показано на рисунке 3.
 
  
  
 +
===Поле прапорів (flags) в заголовку DNS.===
  
Рис.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, а інші два лічильника можуть бути як нульовими, так і ненульовими.
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 запиті===
  
Раздел вопросов в DNS запросе
+
Формат кожного питання в розділі питань (question) показаний на малюнку 4. Зазвичай присутній тільки одне питання.
  
Формат каждого вопроса в разделе вопросов (question) показан на рисунке 4. Обычно присутствует только один вопрос.
+
Ім'я запиту (query name) це шукане ім'я. Воно виглядає як послідовність з однієї або кількох міток. Кожна мітка починається з 1-байтового лічильника, який містить кількість наступних за ним байт. Назва закінчується байтом рівним 0, який є міткою з нульовою довжиною. І є, у свою чергу, міткою кореня. Кожен лічильник байтів повинен бути в діапазоні від 0 до 63, так як довжина мітки обмежена 63 байтами.
 
+
Имя запроса (query name) это искомое имя. Оно выглядит как последовательность из одной или нескольких меток. Каждая метка начинается с 1-байтового счетчика, который содержит количество следующих за ним байт. Имя заканчивается байтом равным 0, который является меткой с нулевой длиной. И является, в свою очередь, меткой корня. Каждый счетчик байтов должен быть в диапазоне от 0 до 63, так как длина метки ограничена 63 байтами.  
+
  
 
   
 
   
  
Рис. 4. Формат раздела вопроса (question) в запросе DNS.  
+
===Формат розділу питання (question) в запиті DNS.===
  
(Дальше в этом разделе мы увидим, что байт счетчик с двумя старшими битами, установленными в 1, значения от 192 до 255, используется в схеме со сжатием.) В отличие от многих других форматов сообщений, которые мы рассмотрели, этому полю разрешено заканчиваться на ограничителе не равном 32 битам. Заполнение не используется.  
+
(Далі в цьому розділі ми побачимо, що байт лічильник з двома старшими бітами, встановленими в 1, значення від 192 до 255, використовується в схемі із стискуванням.) На відміну від багатьох інших форматів повідомлень, які ми розглянули, цьому полю дозволено закінчуватися на обмежувачі не рівному 32 бітам. Заповнення не використовується.
  
На рисунке 5 показано, как хранится имя домена gemini.tuc.noao.edu.  
+
На малюнку 5 показано, як зберігається ім'я домену gemini.tuc.noao.edu.
  
 
   
 
   
  
Рис.5. Представление имени домена gemini.tuc.noao.edu.  
+
Рис.5. Подання імені домену gemini.tuc.noao.edu.
  
У каждого вопроса есть тип запроса (query type), а каждый отклик (называемый записью ресурса, о чем мы поговорим ниже) имеет тип (type). Существует около 20 различных значений, некоторые из которых в настоящее время уже устарели. В таблице 2 показаны некоторые из этих значений. Тип запроса это надмножество (множество, подмножеством которого является данное множество) типов: два из показанных значений, могут быть использованы только в вопросах.  
+
У кожного питання є тип запиту (query type), а кожен відгук (званий записом ресурсу, про що ми поговоримо нижче) має тип (type). Існує близько 20 різних значень, деякі з яких в даний час вже застаріли. У таблиці 2 показані деякі з цих значень. Тип запиту це надмножество (безліч, підмножиною якого є дане безліч) типів: два з показаних значень, можуть бути використані тільки в питаннях.
  
Таблица 2. Значения type и query type для DNS вопросов и ответов.  
+
Таблиця 2. Значення type і query type для DNS питань і відповідей.
Имя
+
Ім'я
Цифровое значение
+
Цифрове значення
Описание
+
Опис
тип (type)?
+
тип (type)?
тип запроса (query type)?  
+
тип запиту (query type)?
A
+
A
1 IP адрес
+
1 IP адреса
·
+
·
·  
+
·
NS
+
NS
2 сервер DNS
+
2 DNS-сервер
·
+
·
·  
+
·
CNAME
+
CNAME
5 каноническое имя
+
5 канонічне ім'я
·
+
·
·  
+
·
PTR
+
PTR
12 запись указателя
+
12 запис покажчика
·
+
·
·  
+
·
HINFO
+
HINFO
13 информация о хосте
+
13 інформація про хості
·
+
·
·  
+
·
MX
+
MX
15 запись об обмене почтой
+
15 запис про обмін поштою
·
+
·
·  
+
·
AXFR
+
AXFR
252 запрос на передачу зоны
+
252 запит на передачу зони
·  
+
·
* или ANY
+
* Або ANY
255 запрос всех записей
+
255 запит всіх записів
·  
+
·
  
  
Наиболее распространенный тип запроса - тип A, который обозначает, что необходим IP адрес для запрашиваемого имени (query name). PTR запрос требует имена, соответствующие IP адресу. Это запрос указателя, который мы опишем в разделе "Запросы указателя" этой главы. Другие типы запросов мы опишем в разделе "Записи ресурсов"  
+
Найбільш поширений тип запиту - тип A, який означає, що необхідний IP адреса для запитуваної імені (query name). PTR запит вимагає імена, відповідні IP адресою. Це запит покажчика, який ми опишемо в розділі "Запити покажчика" цієї глави. Інші типи запитів ми опишемо в розділі "Записи ресурсів"
  
Класс запроса (query class) обычно равен 1, что указывает на адреса Internet. (В некоторых случаях поддерживаются не-IP значения.)  
+
Клас запиту (query class) зазвичай дорівнює 1, що вказує на адреси Internet. (У деяких випадках підтримуються не-IP значення.)
  
Часть записи ресурса в отклике DNS
+
Частина запису ресурсу у відгуку DNS
  
Последние три поля в DNS сообщении это ответы (answers), полномочия (authority) и дополнительная информация (additional information), общий формат называется записью ресурса (RR - resource record). На рисунке 6 показан формат записи ресурса.  
+
Останні три поля в DNS повідомленні це відповіді (answers), повноваження (authority) та додаткова інформація (additional information), загальний формат називається записом ресурсу (RR - resource record). На малюнку 6 показаний формат запису ресурсу.
  
 
   
 
   
  
Рис.6. Формат записи ресурса DNS.  
+
Рис.6. Формат запису ресурсу DNS.
  
Имя домена (domain name) это имя, которому соответствуют следующие данные ресурса. Формат имени домена тот же, что мы описали ранее для поля имени запроса (query name) (рисунок 5).  
+
Ім'я домену (domain name) це ім'я, яким відповідають такі дані ресурсу. Формат імені домену той же, що ми описали раніше для поля імені запиту (query name) (малюнок 5).
  
Тип (type) указывает на один из типов кодов RR. Это то же самое, что и значения типа запроса (query type), которые мы описали раньше. Для данных Internet класс (class) обычно установлен в 1.  
+
Тип (type) вказує на один з типів кодів RR. Це те ж саме, що і значення типу запиту (query type), які ми описали раніше. Для даних Internet клас (class) зазвичай встановлений в 1.
  
Поле время жизни (time-to-live) это количество секунд, в течение которых RR может быть кэширована клиентом. Обычно TTL RR равно 2 дням.  
+
Поле час життя (time-to-live) це кількість секунд, протягом яких RR може бути кешовані клієнтом. Зазвичай TTL RR дорівнює 2 днях.
  
Длина записи ресурса (resource data length) указывает на количество данных ресурса (resource data). Формат этих данных зависит от типа (type). Для типа равного 1 (запись A) данные ресурса - это 4-байтный IP адрес. Сейчас мы описали основной формат DNS запросов и откликов.  
+
Довжина запису ресурсу (resource data length) вказує на кількість даних ресурсу (resource data). Формат цих даних залежить від типу (type). Для типу рівного 1 (запис A) дані ресурсу - це 4-байтний IP адреса. Зараз ми описали основний формат DNS запитів і відгуків.
Запросы указателя
+
Запити покажчика
  
Для понимания работы DNS важно знать, как обрабатываются запросы указателя - задан IP адрес, возвращается имя (или имена), соответствующее этому адресу.  
+
Для розуміння роботи 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.  
+
По-перше, повернемося до малюнка 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.  
+
Ми повинні написати 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 адресе и специальные домены, иногда вносящие определенную путаницу.  
+
Без окремих гілок дерева DNS здійснити перетворення адресу - ім'я, (зворотне перетворення) можна було б тільки починаючи від кореня дерева і переглядаючи кожен домен верхнього рівня. При сьогоднішньому розмірі Internet це могло б зайняти дні або навіть тижні. Використання ж in-addr.arpa прийнятний варіант, незважаючи на переставлені місцями байти в IP адресу та спеціальні домени, іноді вносять певну плутанину.
  
Однако встретиться с доменом in-addr.arpa и переставленными байтами в IP адресе можно только тогда, когда мы общаемся с DNS непосредственно, используя, такие программы как host или просматривая пакеты с использованием tcpdump. При работе приложения, разборщик (gethostbyaddr) обычно воспринимает IP адрес и возвращает информацию о хосте. Перестановка байтов и добавление домена in-addr.arpa осуществляется разборщиком автоматически.  
+
Проте зустрітися з доменом 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. Если и это не сработает, отправитель отработает тайм-аут и повторит попытки позже.  
+
== Записи DNS ==
 +
Записи DNS, або ''Ресурсні записи'' (англ. Resource Records, RR) - одиниці зберігання і передачі інформації в DNS. Кожна ресурсна запис складається з наступних полів:
  
 +
* '''''Ім'я''''' (NAME) - доменне ім'я, до якого прив'язана або якому «належить» дана ресурсна запис;
 +
* '''''TTL''''' (Time To Live) - допустимий час зберігання даної ресурсної записи в кеші не відповідального DNS-сервера;
 +
* '''''Тип''''' (TYPE) ресурсного запису - визначає формат і призначення даного ресурсного запису;
 +
* '''''Клас''''' (CLASS) ресурсного запису; теоретично вважається, що DNS може використовуватися не тільки з TCP / IP, але і з іншими типами мереж, код у полі клас визначає тип мережі;
 +
* '''''Довжина поля даних''''' (RDLEN);
 +
* '''''Поле даних''''' (RDATA), формат і зміст якого залежить від типу запису.
  
NS
+
Найбільш важливі типи DNS-записів:
Запись имени сервера. Указывает на полномочные DNS серверы для домена. Представлена в виде имен доменов (последовательность меток). Мы рассмотрим примеры этих записей в следующем разделе.
+
  
Это общие типы RR.
+
* '''''Запис A''''' (''address record'') або запис адреси, що зв'язує ім'я хоста з IP адресою. Наприклад, запит A-запису на ім'я '''''referrals.icann.org''''' поверне його IP адресу - '''''192.0.34.164'''''
 +
* '''''Запис AAAA''''' (''IPv6 address record'') зв'язує ім'я хоста з адресою протоколу '''IPv6'''. Наприклад, запит AAAA-запису на ім'я '''''K.ROOT-SERVERS.NET''''' поверне його '''IPv6''' адресу - '''''2001:7 fd:: 1'''''
 +
* '''''Запис CNAME''''' (''canonical name record'') або канонічний запис імені (псевдонім) використовується для перенаправлення на інше ім'я
 +
* '''''Запис MX''''' (''mail exchange'') або поштовий обмінник вказує сервер обміну поштою для даного домену.
 +
* '''''Запис NS''''' (''name server'') вказує на DNS-сервер для даного домену.
 +
* '''''Запис PTR''''' (''pointer'') або запис покажчика, що зв'язує IP адресу хоста з його канонічним ім'ям. Запит у домені '''''in-addr.arpa''''' на IP хоста в ''reverse'' формі поверне ім'я ('''FQDN''') даного хоста.
 +
* '''''Запис SOA''''' (''Start of Authority'') або початковий запис зони вказує, на якому сервері зберігається еталонна інформація про даний домен, містить контактну інформацію особи, відповідального за дану зону, таймінги (параметри часу) кешування зонної інформації та взаємодії DNS-серверів.
 +
* '''''Запис SRV''''' (''server selection'') вказує на сервери для сервісів, використовується, зокрема, для '''''Jabber''''' і '''''Active Directory'''''.
  
 
Протокол DNS для роботи використовує 53-й '''TCP'''-або '''UDP'''-порт для відповідей на запити. Традиційно запити і відповіді відправляються у вигляді однієї '''UDP''' датаграми. '''TCP''' використовується для '''AXFR'''-запитів.
 
Протокол DNS для роботи використовує 53-й '''TCP'''-або '''UDP'''-порт для відповідей на запити. Традиційно запити і відповіді відправляються у вигляді однієї '''UDP''' датаграми. '''TCP''' використовується для '''AXFR'''-запитів.

Поточна версія на 12:29, 24 грудня 2010

Формат повідомлень DNS

Для DNS запиту і для DNS відгуку використовується однаковий формат. На малюнку показаний загальний формат DNS повідомлення.


Загальний формат DNS запиту і відповіді.

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

Значення в полі ідентифікації (identification) встановлюється клієнтом і повертається сервером. Це поле дозволяє клієнту визначити, на який запит прийшов відгук.

16-бітове поле прапорів (flags) поділено на кілька частин, як показано на малюнку


Поле прапорів (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 байтами.


Формат розділу питання (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 здійснюється розбирачем автоматично. На латинице

Записи ресурсів

Записи DNS

Записи DNS, або Ресурсні записи (англ. Resource Records, RR) - одиниці зберігання і передачі інформації в DNS. Кожна ресурсна запис складається з наступних полів:

  • Ім'я (NAME) - доменне ім'я, до якого прив'язана або якому «належить» дана ресурсна запис;
  • TTL (Time To Live) - допустимий час зберігання даної ресурсної записи в кеші не відповідального DNS-сервера;
  • Тип (TYPE) ресурсного запису - визначає формат і призначення даного ресурсного запису;
  • Клас (CLASS) ресурсного запису; теоретично вважається, що DNS може використовуватися не тільки з TCP / IP, але і з іншими типами мереж, код у полі клас визначає тип мережі;
  • Довжина поля даних (RDLEN);
  • Поле даних (RDATA), формат і зміст якого залежить від типу запису.

Найбільш важливі типи DNS-записів:

  • Запис A (address record) або запис адреси, що зв'язує ім'я хоста з IP адресою. Наприклад, запит A-запису на ім'я referrals.icann.org поверне його IP адресу - 192.0.34.164
  • Запис AAAA (IPv6 address record) зв'язує ім'я хоста з адресою протоколу IPv6. Наприклад, запит AAAA-запису на ім'я K.ROOT-SERVERS.NET поверне його IPv6 адресу - 2001:7 fd:: 1
  • Запис CNAME (canonical name record) або канонічний запис імені (псевдонім) використовується для перенаправлення на інше ім'я
  • Запис MX (mail exchange) або поштовий обмінник вказує сервер обміну поштою для даного домену.
  • Запис NS (name server) вказує на DNS-сервер для даного домену.
  • Запис PTR (pointer) або запис покажчика, що зв'язує IP адресу хоста з його канонічним ім'ям. Запит у домені in-addr.arpa на IP хоста в reverse формі поверне ім'я (FQDN) даного хоста.
  • Запис SOA (Start of Authority) або початковий запис зони вказує, на якому сервері зберігається еталонна інформація про даний домен, містить контактну інформацію особи, відповідального за дану зону, таймінги (параметри часу) кешування зонної інформації та взаємодії DNS-серверів.
  • Запис SRV (server selection) вказує на сервери для сервісів, використовується, зокрема, для Jabber і Active Directory.

Протокол 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-іменах старші (що знаходяться ближче до кореня) частини розташовані в кінці.

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

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

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

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