Разбираем нестандартный udp dns запрос с помощью tcpdump

Реагируя на очередной «pseudorandom subdomain» (PRSD) DDoS, а они очень хорошо видны на графике исходящих запросов:



Я наткнулся на странный udp запрос.

Стандартный udp запрос-ответ выглядит так:

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)

Но иногда в логах tcpdump можно увидеть следующее:

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)

Запрос почти не изменился, но появилось поле: [b2&3=0x180] ( там могут быть разные значения ).

Что оно означает?

В документации к tcpdump написано:

If any of the response bits are set (AA, RA or rcode) or any of the `must be zero' bits are set in bytes two and three, `[b2&3=x]' is printed, where x is the hex value of header bytes two and three.

Если посмотреть из чего состоит заголовок dns пакета, то можно увидеть следующее:

                                    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                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Нас интересуют поле:

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

Если 0х180 перевести в двоичную систему счисления, то получим:

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

Т.к. байт 16, то итоговое число выглядит так:
0000 0001 1000 0000


Если посмотреть на заголовок пакета, то можно увидеть, что в пакете выставлены биты отвечающие за рекурсию. RD — recursion desired и RA — recursion available.

В исходящем пакете dns запроса не ожидается бит RA, поэтому tcpdump говорит об этом, показывая конструкцию: [b2&3=0x180].

Можно перепроверить себя, чтобы убедиться, что был установлен именно бит RA.
В этом поможет 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)

Сформировав пакет и отослав его, в консоли с tcpdump можно увидеть, что именно об этом поведении и шла речь:

$ 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)