Wireshark, you make me miserable.

I've been working on finding some specific DNS results on my network.

Here's the assignment
1. Locate DNS queries on a sniffer
2. Find "Suspicious IP's" or "Suspicious" DNS replies (confidential)
3. Report back.

Easy enough, right?

Instead of going too low level, I have the luxury of using tshark. So why not?

First, let's look at a DNS reply.

....
<field name="" show="Additional records" size="16" pos="165" value="c075000100010000e76f00044348150b">
<field name="" show="ns2.panthercdn.com: type A, class IN, addr 67.72.21.11" size="16" pos="165" value="c075000100010000e76f00044348150b">
<field name="dns.resp.name" showname="Name: ns2.panthercdn.com" size="2" pos="165" show="ns2.panthercdn.com" value="c075">
<field name="dns.resp.type" showname="Type: A (Host address)" size="2" pos="167" show="0x0001" value="0001">
<field name="dns.resp.class" showname="Class: IN (0x0001)" size="2" pos="169" show="0x0001" value="0001">
<field name="dns.resp.ttl" showname="Time to live: 16 hours, 27 minutes, 27 seconds" size="4" pos="171" show="59247" value="0000e76f">
<field name="dns.resp.len" showname="Data length: 4" size="2" pos="175" show="4" value="0004">
<field name="" show="Addr: 67.72.21.11" size="4" pos="177" value="4348150b">
</field>
.....


The problem is that the field name for the resolved address has no name! So if you wanted you could return data by

~>tshark -i eth0 dns -Tfields dns.resp.name
ns2.panthercdn.com

but you can never simply query for the resolved IP! If you'd like a full reference list of what you can and can't query, check this out http://www.wireshark.org/docs/dfref/d/dns.html .

At least I'm not the only one who thinks this is a feature that should be added. According to the Wireshark wish list:

"PDML output has several fields that do not have a name attribute assigned to them. This creates difficulties in parsing and offline analysis of the XML output from Wireshark. e.g. IP address field in a DNS response does not include the name attribute. (Fields added to the display using proto_tree_add_text() don't have a name related to them. This wish requires the abolishment of this function. Or will an empty name/showname attribute suffice? - Jaap Keuter) (Alternatively, we could just suppress unnamed fields from the PDML output, and turn unnamed fields to named fields as people complain or submit patches. A sweeping change of all unnamed fields would probably only happen over a long period of time. - Guy Harris) "

It looks like I may not get my wish any time soon. So the only solution is a workaround. (I'm getting tired of these types of solutions - for simple annoyances.)

I'm just going to use ruby combined with tshark inline.

tshark -r Desktop/dns.pcap -R dns.flags.response | ruby -e 'while line=STDIN.gets; unless line.scan("response").length.eql?(0); temp=line.split(" "); puts "#{temp[4]} #{temp[10]} #{unless temp[12..temp.length].nil?; temp[12..temp.length].join(" "); end}"; end; end'

This returns

"Caller IP -> Dest Site (or IP) -> resolved IPs (maybe multiples) "

I'm sure that there are sed, awk or bash guru's out there that could write it slimmer, but this seems to work for the time being. Essentially ruby is just being abused as a text parser. I'm thinking about dropping tshark altogether and writing the sniffer using pcaplet. However, this doesn't resolve packets to the application layer so we're stuck text parsing through udp.data text either way. Looks like we're not getting a elegant solution this time.

Like I said, bubble gum and duct tape man.