README 2.04 KB
Newer Older
Stephen Morris's avatar
Stephen Morris committed
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51
"badpacket" is a tool intended to test that a nameserver can cope with
incorrectly-formatted DNS messages.

This particular incarnation of the tool allows the flags field of a DNS message
(the third and fourth bytes) to be set to any bit combination (including ones
that invalid in a query).  As well as setting the bits to a particular
combination, it is possible to specify ranges for bit/field values; when this
is done, the tool will send a set of packets so that each combination of flag
bits is checked.

To illustrate this, consider the following command:

badpacket --address 192.0.2.21 --port 5301 --aa 0-1 --cd 1
          --rc 0-2 ftp.example.com

(The command has been split across two lines for clarity.)

The address and port flags are self-evident.  The other flags specify settings
for the AA bit (0 and 1), CD bit (always 1) and the RCODE field (0, 1, 2). (The
remaining fields are not specified, so will always be zero.)  There are six
combinations of these values, so six packets will sent to the remote server with
the following settings:

AA RCODE  CD Rest
0    0    1   0
0    1    1   0
0    2    1   0
1    0    1   0
1    1    1   0
1    2    1   0

Each packet will cause a line to be output to stdout, which will have the
following form:

SUCCESS: (QR:0 OP:0 AA:0 TC:0 RD:0 RA:0 Z:0 AD:0 CD:1 RC:0)
         (qr:1 op:0 aa:0 tc:0 rd:0 ra:1 z:0 ad:0 cd:1 rc:0)

(Again the text has been split across two lines for clarity.)

Each lines contains a status (SUCCESS indicates that a response was received,
regardless of the contents of the response), the state of the fields in the
flags word of the packet sent (in upper-case letters) and the state of the
fields in the flags word of the response (in lower-case letters).

TODO: At the moment the tool is limited to just alerting the flags field.
Future work should extend the program to other bad packets. Ideas are:

* Flasify the values in the various count fields
* Add data to sections that should be empty.
* Deliberately mangle the names placed in the message sections (e.g. by altering
  the label count fields).