Почему QNAME для этого DNS q. заканчивается символом NULL?

я контролировала порт 5353 (MDNS) с WireShark и наткнулся на следующий вопрос DNS:Почему QNAME для этого DNS q. заканчивается символом NULL?

В соответствии с разделом 4.1.2 RFC 1035 QNAME является:

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

Это, похоже, противоречит тому, что я вижу по проводу в захвате выше. Последняя метка заканчивается c0 12 вместо 00. Почему это и почему оно не задокументировано в RFC?

источник

2016-08-09 Nathan Osman

Возможно похожие: я нашел [это] (https://github.com/wireshark/wireshark/blob/53de2c23783788d92dc17d3dccfdc8b65ab0bf74/epan/dissectors/packet-dns.c#L1261) в DNS диссектора в WireShark исходный код. –

По-видимому, когда последовательность меток заканчивается c0 12, это указывает на косвенный указатель. Это примерно эквивалентно утверждению «перейдите к этому смещению в DNS-запросе и продолжайте читать оттуда».

Первые два бита являются константой (c0), а остальные 14 бит являются смещением от начала запроса. В моем вопросе, например, c0 12 указывает, что следующая часть QNAME должна состоять из 47 байтов в запрос.

05 6c 6f 63 61 6c 00 .local.

источник

2016-08-09 20:01:29

yep, задокументировано в 4.1.4 –

@DusanBajic Я нахожу это немного контр-интуитивным, что они документируют его _later_ в документе, а не покрывают его в этом разделе. –

кажется ответом на то, что в 4.1.2: 'В разделе содержится QDCOUNT (обычно 1) записи ...' - похоже, что случай с несколькими запросами в том же сообщении должен был быть очень редкими. Кстати, я нашел ваш вопрос интригующим и исследованным, так как я не знал ответа, я пару секунд опоздал :), все же, узнал что-то новое. –

Почему QNAME для этого DNS q. заканчивается символом NULL?

ответ

Смежные вопросы