Parse custom udp dns request using tcpdump

Reacting to the next “pseudorandom subdomain” ( PRSD ) DDoS, and they are very clearly visible on the graph of outgoing requests:



I came across a strange udp request.

The standard udp request-response looks like this:
')

20: 14: 17.533119 IP [ip-address] .60000> [resolver-ip] .53: 31337+ A? ya.ru. (23)
20: 14: 17.534871 IP [resolver-ip] .53> [ip-address] .60000: 31337 3/0/0 A 213.180.204.3, A 213.180.193.3, A 93.158.134.3 (71)

But sometimes in the tcpdump logs you can see the following:

20: 16: 43.333220 IP [ip-address] .60000> [resolver-ip] .53: 31337+ [b2 & 3 = 0x180] A? ya.ru. (23)
20: 16: 43.336146 IP [resolver-ip] .53> [ip-address] .60000: 31337 3/0/0 A 213.180.193.3, A 213.180.204.3, A 93.158.134.3 (71)

The request almost did not change, but the field appeared: [b2 & 3 = 0x180] (there may be different values).

What does it mean?

The tcpdump documentation says:

There are two bits of three, and there can be no more than a bit. header bytes two and three.

If you look at what the dns header of the package consists of , you can see the following:

                                     1 1 1 1 1 1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
     |  ID |
     + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
     | QR |  Opcode | AA | TC | RD | RA |  Z |  RCODE |
     + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
     |  QDCOUNT |
     + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
     |  ANCOUNT |
     + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
     |  NSCOUNT |
     + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
     |  ARCOUNT |
     + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +

We are interested in the field:

| QR | Opcode | AA | TC | RD | RA | Z | RCODE |

If 0x180 translate into a binary number system, we get:

$ echo 'ibase = 16; obase = 2; 180' | bc
1 1000 0000

Since byte 16, then the final number looks like this:
0000 0001 1000 0000


If you look at the header of the packet, you can see that the packet contains bits responsible for the recursion. RD - recursion desired and RA - recursion available.

In the outgoing packet of the dns request, the RA bit is not expected, so tcpdump says this by showing the construct: [b2 & 3 = 0x180].

You can double-check yourself to make sure that the RA bit was set.
This will help scapy :

#!/usr/bin/env python from scapy.all import * pkt=IP(dst="[resolver-ip]")/\ UDP(sport=60000)/\ DNS(id=31337,qr=0,rd=1,ra=1,qd=DNSQR(qname="ya.ru")) pkt.show2() send(pkt) 

Having formed a packet and having sent it, you can see in the console with tcpdump what exactly this behavior was about:

$ sudo tcpdump -n -i eth0 port 53 and host [resolver-ip]

20: 17: 43.975572 IP [ip-address] .60000> [resolver-ip] .53: 31337+ [b2 & 3 = 0x180] A? ya.ru. (23)
20: 17: 43.979447 IP [resolver-ip] .53> [ip-address] .60000: 31337 3/0/0 A 93.158.134.3, A 213.180.204.3, A 213.180.193.3 (71)