Как понимать dns-секцию дополнительной информации?

В общем, купил доменное имя у регистратора Д.И. и в настройках ответственного dns-сервера указал свой ip-адрес, далее открыл сокет (53-порт) для прослушивания дейтаграмм. Через браузер firefox ввел купленное доменное имя, получил dns-сообщение и принялся его разбирать.

Изучив rfc-1035 и опираясь на эти знания разобрал заголовок, вопросительный раздел, ответ, но с разделом доп. информации я просто стою на месте уже пару дней, не могу понять его структуру, хотя в рфц указано что раздел ответа,полномочий и дополнительный имеют одинаковую структуру т.е. в начале записи доменное имя(метки или указатель) и т.д..

На изображении в первой строке символьное представление днс-запроса во второй строке оно интерпретировано в числа, все символы и числа разделены штрихом шеффера для удобства чтения. Заголовка dns нет в изображении но имеется в виду что это запрос, 1-запись в вопросительном разделе (типа А) и 1-запись в разделе доп. информации. По другому изображение начинается с первой метки доменного имени.

После красной черты начинается не понятная мне сигнатура, но это первый байт после вопросительного раздела. Сообщение отображено как есть т.е. с прямым порядком байт и числа типа "unsigned char":

Скриншот терминала

Помогите пж.


Ответы (1 шт):

Автор решения: Nofate

Попробуем разобраться

Согласно rfc-1035 RR записи начинаются с доменного имени, за которым следуют два октета, кодирующие тип записи (TYPE).

В вашем случае доменное имя это 0 - корень. А TYPE - 0 41. В вики узнаем, что тип 41 это OPT pseudo-record type needed to support EDNS, псевдо-запись для поддержки расширений DNS, регламентированных rfc6891.

Идем в rfc6891 и смотрим на структуру записи OPT:

   +------------+--------------+------------------------------+
   | Field Name | Field Type   | Description                  |
   +------------+--------------+------------------------------+
   | NAME       | domain name  | MUST be 0 (root domain)      |
   | TYPE       | u_int16_t    | OPT (41)                     |
   | CLASS      | u_int16_t    | requestor's UDP payload size |
   | TTL        | u_int32_t    | extended RCODE and flags     |
   | RDLEN      | u_int16_t    | length of all RDATA          |
   | RDATA      | octet stream | {attribute,value} pairs      |
   +------------+--------------+------------------------------+

Итак, NAME у нас 0, TYPE - 0 41. Далее следует 2 октета размера UDP пакета - 5 200, то есть 5 << 8 + 200 = 1480.

Потом четыре октета RCODE и флагов. Их структура описана отдельно:

              +0 (MSB)                            +1 (LSB)
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: |         EXTENDED-RCODE        |            VERSION            |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | DO|                           Z                               |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Из вашего примера выходит, что:

  • EXTENDED-RCODE 0
  • VERSION 0
  • DO 1
  • флаги Z 0

И завершает все размер RDLEN 0, то есть дополнительных опций нет.


Если говорить о смысле всего этого, то отправитель передает флаг DO, чтобы заявить, что готов получать в ответе RR записи DNSSEC.

→ Ссылка