rend: v. tr. To tear or split apart or into pieces violently. $Id: README,v 1.16 2010/06/03 15:19:28 james Exp $ 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 dealt with DNS servers that put looping compression pointers in replies or pointers to the wrong part of the packet, load balancing switches that set various header bit-flags seemingly at random, and a DNS server that adds resource records to a reply without announcing them in the header, and plenty others. dnsrend is some perl that will rend a DNS packet, in place of my pencil and pad. It reads libpcap packet capture data or tcpdump's hex output and gives a laborious dissection of the packet. It supports IPv4 and IPv6 transport. You will need the Net::Pcap module and version 0.04 or newer of Net::Pcap::Reassemble to read libpcap data. Net::Pcap::Reassemble is required to reassemble IP fragments so fragment support is available only when reading libpcap data. It is not an introductory tool. It is for those of us who already understand how a packet should be composed and want to examine byte-by-byte a packet we suspect is broken. USAGE Options: -a filename Read tcpdump ASCII/hex output. Use `-' for stdin. -D Data is a DNS message without any L2/3 header. Give dnsrend the output of tcpdump -n -s 4096 -w - udp port 53 Why 4kB? Because with the onset of EDNS and OPT records the historic 512 byte limit for UDP DNS packets can, with the mutual consent of the communicating parties, be ignored. Beware that 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. Check your tcpdump man page. Examples: tcpdump -n -s 4096 -w - udp port 53 | dnsrend | less (libpcap) tcpdump -xnl -s 4096 udp port 53 | dnsrend -a - | less or tcpdump -n -s 4096 -w dns.packets udp port 53 then dnsrend dns.packets | less Read the output carefully. 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. Because it's intended to continue parsing DNS messages even in the face of total junk dnsrend can generate lots of warnings from perl (about undefined values, out of bounds reads, etc). These are harmless but clutter up the display. Redirect stderr to null to eliminate them. dnsrend has 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. PROBLEM REPORTING If you want to report a problem, submit a patch or a comment please email . Please include as much information about your problem as you can. Some things which are especially useful are - what version of perl you are using (``perl -v'') - what version of tcpdump you are using Remember -- I can't see your computer and I didn't see what you tried to do. You'll have to tell me! There are two fine essays on the topics of bug reporting and requesting help available on the web. I strongly suggest you invest a little time to read them. They're entertaining _and_ educational! How to Report Bugs Effectively, by Simon Tatham: http://www.chiark.greenend.org.uk/~sgtatham/bugs.html How To Ask Questions The Smart Way, by Eric Steven Raymond: http://www.tuxedo.org/~esr/faqs/smart-questions.html THANKS A thank you to people who've helped out; Mark Campbell, DCU School of Computer Applications and Philip Reynolds, RFC Networks (www.rfc-networks.ie) for giving me large samples of captured DNS packets. $Id: README,v 1.16 2010/06/03 15:19:28 james Exp $