Microsoft has issued security recommendations to reduce the vulnerability of the NXNSA attack on DNS servers, which can be used to enhance a single DNS query in a DDoS attack against authoritative DNS servers.

In a recent paper, researchers at Tel Aviv University and the Interdisciplinary Center discovered a new vulnerability called NXNSAattack that can be used to launch a devastating attack on both recursive converters and authoritative servers. A knockout post Outsource hosting support.

That’s why NXNSAattack works by sending a DNS query for a domain under the control of an attacker to a recursive server. Since this recursive server does not have permission to resolve the request, it sends a request to an authoritative DNS server for the attacker’s domain.

The authorization server is also under the attacker’s control and responds with a list of servers to be requested by the original UPS. However, this list of servers will be the target of the DNS DDoS attack that now needs to be queried.

If many requests are made in this way, the attacker can quickly escalate the attack on the DDoS of the authoritative DNS server and make it immune to the attack.

This attack is illustrated by the image created in his blog about the NXNSA attack.

NXNSAattack flow rate NXNSAattack flow rate (source:

According to the researchers, this attack has a gain of more than 1620x on the number of packets exchanged by the recursive resolver, which can damage their targets.

To address this vulnerability, DNS server developers have begun providing recommendations and patches for their software.  Below is a list of the currently known recommendations.

More information about NXNSAttack can be found on the website, created by researchers, and we recommend that you read the post on the blog.

Mitigation of the NXNSA attack on Windows DNS servers

Yesterday, Microsoft published the advice ADV200009 | Windows DNS Server Denial of Service Vulnerability with NXNSAattack DNS Attack Mitigation.

An attacker who successfully exploits this vulnerability can cause the DNS server service to stop responding to requests.

To exploit this vulnerability, an attacker must have access to at least one client and a domain that responds with a large number of reference folders, without glue points to the victim’s external subdomains. When resolving an attacking client’s name, the resolver contacts the victim’s domain for each reference file found. This action could result in a large number of connections between the victim’s recursive resolver and the victim’s authoritative DNS server to trigger a Distributed Denial of Service (DDoS) attack, according to ADV200009, a Microsoft security consultant.

To limit this attack, Microsoft recommends administrators use the PowerShell Set-DnserverResponseRateLimiting command to limit the response time.

Response speed limitation is a configuration option used by DNS servers to prevent them from being used in DNS-enhanced DDoS attacks.

When enabled, this setting limits the number of responses or errors the DNS server sends to a DNS client per second.

To check the current settings for response limitation, you can run the Get-DnserverResponseRateLimiting PowerShell command.

Get-DnserverResponseRateLimiting command Get-DnserverResponseRateLimiting command

As you can see in the default settings above, a Windows DNS server only responds to the client five times in one second.

If you want to increase or decrease this amount, you can do so using the Set-DnserverResponseRateLimiting PowerShell cmdlet.

For example, to reduce the number of responses to two per second, run the following command:

Set-DnsServerResponseRateLimiting – Persian reaction limitation 2

Set-DnserverResponseRateLimiting command Set-DnserverResponseRateLimiting command

A similar command can be used to reduce the number of errors to two per second:

Set-DnsServerResponseRateLimitation -ErrorsPerSec 2

Note that using the response time limitation feature prevents the Windows DNS server from being used in case of DNS attacks on another client. However, this does not protect the server itself from the risk of being compromised.

Unfortunately, Microsoft did not provide recommended values to limit this attack.

BleepingComputer asked Microsoft for additional information, but received no response.