Guidance for DNS amplification discussed in ADV200009

View products that this article applies to.

Summary

Abstract

On May 19, 2020, Microsoft released security advisory ADV200009. This advisory describes a DNS amplification attack that was identified by Israeli researchers. The attack, known as NXNSAttack, can target any DNS server, including Microsoft DNS and BIND servers that are authoritative for a DNS zone.

For DNS servers that reside on corporate intranets, Microsoft rates the risk of this exploit as low. However, DNS servers that reside on edge networks are vulnerable to NXNSAttack. Pre-Windows Server 2016 DNS servers that reside on edge networks should be upgraded to Windows Server 2016 or later versions that support the Response Rate Limit (RRL). RRL reduces the amplification effect when a targeted DNS resolver queries your DNS servers.

Symptoms

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.

Attack overview

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

Internal, private domains are not resolvable through Root Hints and top-level domain DNS servers. When you follow best practices, DNS servers that are authoritative for private, internal domains, such as Active Directory domains, are not reachable from the internet.

Although an NXNSAttack of an internal domain from the internal network is technically possible, it would require a malicious user on the internal network who has administrator-level access to configure internal DNS servers to point to DNS servers in the attacker domain. This user must also be able to create a malicious zone on the network and put a special DNS server that is capable of performing the NXNSAttack on the corporate network. A user who has this level of access will generally favor stealth over announcing their presence by initiating a highly visible DNS DDoS attack.

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.

↑ Back to the top

Resolution

To resolve this issue, use the following method for the appropriate server type.

For intranet-facing MS DNS servers

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.

For edge-facing Authoritative DNS servers

Enable RRL that is supported by Windows Server 2016 and later versions of Microsoft DNS. Using RRL on DNS resolvers minimizes the initial attack amplification. Using RRL on a public domain authoritative DNS server reduces any amplification that is reflected back to the DNS resolver. By default, RRL is disabled. For more information about RRL, see the following articles:

What's New in DNS Server in Windows Server
SetDNSServerResponseRateLimiting PowerShell cmdlet

Run the SetDNSServerResponseRateLimiting PowerShell cmdlet to enable RRL by using default values. If enabling RRL causes legitimate DNS queries to fail because they are being throttled too tightly, incrementally increase the values for the Response/Sec and Errors/Sec parameters only until the DNS server responds to previously failing queries.

Other parameters may also help administrators better manage RRL settings. These settings include RRL exceptions.

For more information, see the following Microsoft Docs article:

DNS Logging and Diagnostics

↑ Back to the top

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.

↑ Back to the top