4

I was monitoring port 5353 (mDNS) with WireShark and came across the following DNS question:

enter image description here

According to section 4.1.2 of RFC 1035 QNAME is:

a domain name represented as a sequence of labels, where each label consists of a length octet followed by that number of octets. The domain name terminates with the zero length octet for the null label of the root...

This seems to contradict what I'm seeing over-the-wire in the capture above. The last label ends with c0 12 instead of 00. Why is this and how come it isn't documented in the RFC?

Nathan Osman
  • 71,149
  • 71
  • 256
  • 361
  • Possibly related: I found [this](https://github.com/wireshark/wireshark/blob/53de2c23783788d92dc17d3dccfdc8b65ab0bf74/epan/dissectors/packet-dns.c#L1261) in the DNS dissector in the WireShark source code. – Nathan Osman Aug 09 '16 at 18:34

1 Answers1

3

Apparently, when a label sequence ends with c0 12, this indicates an indirect pointer. It is roughly equivalent to stating "go to this offset in the DNS query and continue reading from there".

The first two bits are a constant (c0) and the remaining 14 bits are the offset from the start of the query. In my question, for example, c0 12 indicates that the next part of the QNAME should come from 47 bytes into the query.

05 6c 6f 63 61 6c 00    .local.
Nathan Osman
  • 71,149
  • 71
  • 256
  • 361
  • yep, documented in 4.1.4 – Dusan Bajic Aug 09 '16 at 20:08
  • @DusanBajic I find it a bit counter-intuitive that they document it _later_ in the document instead of covering it in that section. – Nathan Osman Aug 09 '16 at 20:09
  • 1
    seems the answer to that is in 4.1.2: `The section contains QDCOUNT (usually 1) entries...` - looks like the case with more than one query in the same message was supposed to be very rare. Btw, I found your question intriguing and investigated since I did not know the answer, I was couple of seconds late :), still, learned something new. – Dusan Bajic Aug 09 '16 at 20:18
  • 1
    @DusanBajic that's cool :) I only figured out what was happening by reading the source code for WireShark's DNS dissector. – Nathan Osman Aug 09 '16 at 20:20
  • my calculation is a bit different, if you re-encode the hex c012 to binary (`parseInt('c012', 16).toString(2)`) you get `1100000000010010`, and that (`parseInt(10010, 2)`) gives 18. left shift by 5 (not sure why) and you get 576 which is the exact number of bytes offset to read the dot in `.local`. i am not convinced of my approach at all, but i do not understand where 47 comes from or how 47 associates with the offset of `.local` – Dave Ankin Dec 29 '21 at 05:28