When a DNS amplification attack is made, you may observe one or more of the following symptoms on an affected server:
- CPU usage for DNS is elevated.
- DNS response times increase and responses may stop.
- An unexpected number of NXDOMAIN responses are generated by your authentication server.
DNS servers have always been vulnerable to an array of attacks. For this reason, DNS servers are generally placed behind load balancers and firewalls in a DMZ.
To exploit this vulnerability an attacker would have to have multiple DNS clients. Typically, this would include a botnet, access to dozens or hundreds of DNS resolvers that are capable of amplifying the attack, and a specialized attacker DNS server service.
The key to the attack is the specially built attacker DNS server that is authoritative for a domain that the attacker owns. For the attack to be successful, the DNS resolvers have to know how to reach the attacker’s domain and DNS server. This combination can generate lots of communication between the recursive resolvers and the victim's authoritative DNS server. The result is a DDoS attack.
Vulnerability for MS DNS on corporate intranets
Vulnerability for edge-facing MS DNS
A DNS resolver on the internet uses Root Hints and Top-Level Domain (TLD) servers to resolve unknown DNS domains. An attacker can use this public DNS system to use any internet-facing DNS resolver to try NXNSAttack amplification. After an amplification vector is discovered, it can be used as part of a denial of service (DDoS) attack against any DNS server that hosts a public DNS domain (the victim domain).
An edge DNS server that acts as a resolver or forwarder can be used as an amplification vector for the attack if unsolicited incoming DNS queries that originate from the internet are allowed. Public access allows a malicious DNS client to use the resolver as part of the overall amplification attack.
Authoritative DNS servers for public domains must allow unsolicited incoming DNS traffic from resolvers that are doing recursive lookups from the Root Hints and TLD DNS infrastructure. Otherwise, access to the domain fails. This causes all public domain authoritative DNS servers to be possible victims of an NXNSAttack. Edge-facing Microsoft DNS servers should run Windows Server 2016 or a later version to gain RRL support.
The risk of this exploit is low. Monitor internal DNS servers for unusual traffic. Disable internal NXNSAttackers that reside on your corporate intranet as they are discovered.
Other parameters may also help administrators better manage RRL settings. These settings include RRL exceptions.
Frequently asked questions
Q1: Does the mitigation that is summarized here apply to all versions of Windows Server?
A1: No. This information does not apply to Windows Server 2012 or 2012 R2. These legacy versions of Windows Server do not support the RRL feature that reduces the amplification effect when a targeted DNS resolver queries your DNS servers.
Q2: What should customers do if they have DNS servers that reside on edge networks that are running either Windows Server 2012 or Windows Server 2012 R2?
A2: DNS servers that reside on edge networks that are running either Windows Server 2012 or Windows Server 2012 R2 should be upgraded to Windows Server 2016 or later versions that support RRL. RRL reduces the amplification effect when a targeted DNS resolver queries your DNS servers.
Q3: How can I determine whether RRL is causing legitimate DNS Queries to fail?
A3: If RRL is configured to LogOnly mode, the DNS server does all the RRL calculations. However, instead of taking preventive actions (such as dropping or truncating responses), the server instead logs the potential actions as if RRL were enabled, and then continues to provide the usual responses.