DNS message dissector
MD5 (dnsrend-0.08.tar.gz) = 83a1059f84b25223a0189edb92db43e5 Released 8th November 2010
Copyright (c) 2003-2010 James Raftery. All rights reserved.
What is dnsrend?
rend: v. tr. To tear or split apart or into pieces violently.
dnsrend decodes DNS messages in excruciating detail.
Faced with broken DNS software spitting out junk DNS packets there is only one satisfactory way to understand the problem: get a pencil and pad, tcpdump and start reading hex. I've seen DNS servers put looping compression pointers in replies or pointers to the wrong part of the packet, load balancings that set header bit-flags seemingly at random, a DNS server that adds resource records to a reply without announcing them in the header, and plenty others.
dnsrend supports IPv4 and IPv6 and uses the Net::Pcap::Reassemble module to transparently handle fragmented UDP datagrams. Net::Pcap::Reassemble can read ethernet (DLT_EN10MB), loopback (DLT_LOOP & DLT_NULL), Linux `cooked' (DLT_LINUX_SLL) and raw (DLT_RAW) libpcap captures.
I was frustrated debugging a problem with a Cisco Distributed
dig wasn't helping.
;; ns_initparse: Message too long
Realising that yet again I was going to decode a DNS message by hand I
dnsrend to do it for me instead.
Feed dnsrend pcap capture data on stdin or from a saved file:
# tcpdump -n -s0 udp port 53 | dnsrend > output.log
# tcpdump -n -s0 -w capturefile.pcap udp port 53
# dnsrend capturefile.pcap > output.log
Input is in tcpdump's hex/ascii format (the -x option to tcpdump)
DNS only. Each `packet' is just the DNS payload. No network/transport headers are removed.
dnsrend can decode RDATA in A AAAA SOA MINFO RP SRV MX RT AFSDB TXT X25 HINFO ISDN SPF OPT LOC SSHFP NAPTR DNSKEY KEY NSEC NXT RRSIG SIG DS DLV resource records.
- It has only rudimentary support for parsing TCP DNS messages. The limitation is that the complete DNS message must be contained in one TCP datagram. I haven't yet found a TCP stream reassembler that I'm happy with.
- Your tcpdump may buffer its output so dnsrend may have to wait for more than one packet to arrive before tcpdump will supply it the contents of its output buffer. Some platforms have a -U tcpdump option to make the pcap output unbuffered.
Review the full output from that broken Distributed Director. See how it set the *COUNT fields to zero but tacked a stray SOA resource record onto the end of the message? And the malformed SOA RNAME field? Faced with such a reply, DiG merely barfs like this.
In an effort to make your life a little easier, the output tries to use uniform keywords to help you pick out messages of significant interest. dnsrend will say ``BAD'' for errors, and ``ODD'' for unusual observations.
If clicking's not your thing, this is just the question section from a packet:
Reading Question section (QDCOUNT is 1) Starting to read a question Starting to read a domain name read 1 octets (0x03) starting at octet 12 Length of next label is 0x03 (decimal 3) octets read 1 octets (0x66) starting at octet 13 Octet 1/3 is: f read 1 octets (0x6f) starting at octet 14 Octet 2/3 is: o read 1 octets (0x6f) starting at octet 15 Octet 3/3 is: o Label is 'foo' Name so far is: foo read 1 octets (0x03) starting at octet 16 Length of next label is 0x03 (decimal 3) octets read 1 octets (0x63) starting at octet 17 Octet 1/3 is: c read 1 octets (0x6f) starting at octet 18 Octet 2/3 is: o read 1 octets (0x6d) starting at octet 19 Octet 3/3 is: m Label is 'com' Name so far is: foo.com read 1 octets (0x00) starting at octet 20 Zero octet, end of name, append root label This name is 'foo.com.' QNAME is: foo.com. read 2 octets (0x000f) starting at octet 21 QTYPE is 0x000f (MX / decimal 15) read 2 octets (0x0001) starting at octet 23 QCLASS is 0x0001 (IN / decimal 1) foo.com. IN MX End of Question section
Look through the full output from a series of packets to see the full details.
The dnsrend program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.