First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
0

dns.length field/filter shows nothing

  • retag add tags

according the display filter reference https://www.wireshark.org/docs/dfref/... the field dns.length is the "Length". I assume it's a length of DNS payload ( dns.length=udp.length - 20 (UDP header)). If I type "dns.length" (which means "dns.length is present") or "dns.length > 0" (which means dns.length is greater than 0) in the display filter field there are no matches. I If type "dns", wireshark shows all DNS packets. Other dns fields like "dns.resp.len" work as expected. Tested with both Wireshark versions 3.2.0 and 2.6.14

kaos's avatar
13
kaos
asked 2020-02-02 21:37:51 +0000
edit flag offensive 0 remove flag close merge delete

Comments

1

I've just consulted source code:

  if (transport == DNS_TRANSPORT_TCP) {
/* Put the length indication into the tree. */
proto_tree_add_item(dns_tree, hf_dns_length, tvb, offset - 2, 2, ENC_BIG_ENDIAN);

}

    { &hf_dns_length,
  { "Length", "dns.length",
    FT_UINT16, BASE_DEC, NULL, 0x0,
    "Length of DNS-over-TCP request or response", HFILL }},

it seems the dns.length field is present only in DNS-over-TCP request or response, why not in DNS-over-UDP?

kaos's avatar kaos (2020-02-02 21:50:29 +0000) edit

I workaround this limitation by calculating ip.len - 28 for DNS-over-UDP and ip.len - 40 for DNS-over-TCP

kaos's avatar kaos (2020-02-03 00:11:55 +0000) edit
add a comment see more comments

1 Answer

1

https://tools.ietf.org/rfc/rfc1035.txt

4.2.1. UDP usage

Messages sent using UDP user server port 53 (decimal).

Messages carried by UDP are restricted to 512 bytes (not counting the IP
or UDP headers).  Longer messages are truncated and the TC bit is set in
the header.

4.2.2. TCP usage

Messages sent over TCP connections use server port 53 (decimal).  The
message is prefixed with a two byte length field which gives the message
length, excluding the two byte length field.  This length field allows
the low-level processing to assemble a complete message before beginning
to parse it.
Chuckc's avatar
3k
Chuckc
answered 2020-02-02 23:52:05 +0000
edit flag offensive 0 remove flag delete link

Comments

thank you for the clarification bubbasnmp! accepted as answer. Cannot upvote as I have not enough points :-(

kaos's avatar kaos (2020-02-03 00:09:55 +0000) edit

And this is because:

UDP is a protocol that offers, to protocols running on top of it (such as DNS), a "service" in which a "packet", with defined packet boundaries, can be sent, so a single DNS message can be sent in a single UDP message.

TCP, however, is a protocol that offers, to protocols running on top if it (such as DNS), a "service" in which you just send a stream of bytes, with no packet boundaries. This requires many protocols to impose their own packet boundaries; DNS does this by putting that additional length field at the beginning of each DNS packet, so that the receiver knows when that DNS packet ends, and the next DNS packet begins, in the byte stream.

Guy Harris's avatar Guy Harris (2020-02-03 01:27:03 +0000) edit
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer