I got the other day an automated mail alert from some ID/IPS equipment that ‘ a NULL DNS scan was detected and blocked from your IP’. NULL DNS scan? I wasn’t sending any such packets, not to mention I have no idea what they mean by that. After some packet level investigation here is what happened.
I was scanning the Internet space for open DNS resolvers for my security project, and was doing it with
nmap –sU –p 53 –n -script=dns-recursion. This scan in turn is supposed to send dull and completely legitimate A record query for a www.wikipedia.org domain and if the target answers it, then it is an open DNS resolver. Still, somehow it triggered an alert on NULL DNS, which does exist by the way as an experimental record but has nothing to do with the NMAP scan.
Doing the scan again with wireshark running I saw to my surprise the following packet (usually 2 of them) being send before NMAP sends the aforementioned www.wikipedia.org request:
called Server Status request (OPCODE 2 see details here https://www.ietf.org/rfc/rfc1035.txt) and was meant to be used by DNS server admins for various management and health check purposes. And of course it is highly unexpected and naturally rejected when coming from the Internet. But why does NMAP send this packet? Turns out (thanks to David Fifield, one of the NMAP developers) when NMAP does UDP scan, beyond what you specify on the cli it adds various payloads depending on the destination port, all taken from /usr/share/nmap/nmap-payloads. The port 53 UDP scan has there the payload:
# DNSStatusRequest udp 53 "\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00"
which includes a lot of x00 in the packet, which in turn seems to trigger the alert on NULL scan. NMAP sends such payloads in UDP scan in order not to send an empty UDP packet, i.e. it thinks “something is better than nothing”. To fix this there are 2 ways:
- specify 0 data length for UDP packet: "--data-length 0"
- comment out with # the needed port section in /usr/share/nmap/nmap-payloads