Mitigating NXDOMAIN Attacks with AWS Route 53 Strategies

Nothing fancy about this, I want to share an incident relating to NXDOMAIN attacks that I encountered pretty long ago. NXDOMAIN attacks can occur to any provider, but in this blog, I want to talk about AWS Route 53.

What is NXDOMAIN attack?

For those who don’t know about NXDOMAIN attacks, it’s a type of DDoS attack in which attackers often use DNS resolvers known as “good” and send a massive number of requests for non-existent subdomains. For example, if your domain record (e.g. example.com) is in a Route 53 hosted zone, and you basically just create an A record for this main domain and don’t have any records for subdomains (e.g. any-sub.example.com), the attackers take advantage of this loophole to cause damage to your brand, often resulting in lost revenue and a tarnished reputation.

Furthermore, these attacks may aim to affect the cache of the recursive resolver, the availability of the authoritative resolver, or serve as DNS reconnaissance to uncover hosted zone records.

If you use Route 53 as your authoritative resolver, Route 53 mitigates the risk of availability/performance impact, but this comes with a cost. You may see a big jump in the cost of Route 53 for the DNS-Queries usage type (can check this on AWS Cost Explorer). And if you don’t prevent it in time, your bill that month could be added with an extra few thousand bucks or more when the attack occurs constantly over a long period of time.

If your organisation has an on-premise DNS server and uses it as your authoritative resolver, your DNS server may be impacted and exhaust resources soon if you don’t intervene on time.

Solutions

Route 53 Strategies

We can leverage Route 53 pricing to see which type of DNS queries are free. Normally, you won’t be charged if:

• Queries to the domain or subdomain name (example.com or my-sub.example.com) must match the record name AND the record type (A). For example, if you have a record created with the name my-sub.example.com and type is A record, and someone queries your domain my-sub.example.com with type AAA, you will be charged for those queries. If they query the domain with type A, you won’t be charged. Additionally, if they query a domain or subdomain that doesn’t exist, you will also be charged.
• Configure the Route 53 record with an alias target that is an AWS resource other than another Route 53 record. For example, you can specify endpoints such as an Amazon CloudFront distribution, an Elastic Load Balancer, an EC2 instance, or an Amazon S3 bucket to the Route 53 record so that the domain or subdomain is always resolved to the IP of those configured endpoints; you won’t be charged in this case. If you configure the record of a domain or subdomain to point to another Route 53 record such as another.second-example.com, you will be charged at standard pricing.

With that being said, I assume you have created your domain (example.com) with type A in most cases. But subdomains are the main part being targeted, and we may often leave them unconfigured by default.

We simply create a wildcard record, for example, *.example.com with a type A (Alias). And we point this record to any AWS resource that we want it to serve the requests. For instance, I point *.example.com with a type A (Alias) to an EC2 instance where it hosts my web server. When someone sends a flood of queries to random12312312.example.com or any other random <sub-domain>.example.com, those queries are resolved to the IP of the EC2 instance then.

If the sub-domains are related to a website, it becomes your choice to either let the web server process to receive or reject those queries. You can configure the web server to handle this part; for example, I have an Nginx web server to serve those requests. I can configure a default site to return a 404 error to any request with non-existent subdomains. The configuration looks like

# Other configurations ....

http {

  # Other configurations ....
  
  # Reject URL like non-exist-subdomain.example.com for http and https
  server {
    listen 80 default_server;
    return 404;
  }
  
  server {
    listen 443 default_server ssl http2;

    ssl_certificate     /path/to/your/ssl/certs/fullchain.pem;
    ssl_certificate_key /path/to/your/ssl/certs/privkey.pem;

    return 404;
  }
}

If someone queries random12312312.example.com, the web server returns a 404 error. You can always find a way that is suitable for your application or architecture to handle the requests.

Other solutions with cost:

• Enable Route 53 Resolver DNS Firewall. Please look at Route 53 pricing to know more about the cost.
• Deploy AWS WAF (web application firewall) + Rate Limiting.
• Set the TTL on the wildcard subdomain higher, for example, 86400 seconds (1 day), to reduce overall query load. This doesn’t stop NXDOMAIN attacks completely but reduces DNS cost somewhat. Please bear in mind that you should tailor the TTL setting based on the purpose of those domains.

Strategies for other DNS resolvers

For other DNS resolvers, there are quite a lot of ways that we can apply to mitigate NXDOMAIN attacks, you may want to research a bit to find what is the best solution for your case. I can recommend few solutions here:

• Similar to Route 53, create *.example.com with a type A (Alias) but pointing to a black hole IP instead, for example 203.0.113.249, you can learn more about the reserved IP networks from here.
• Consider to install/setup Firewall hardwares with Advanced Firewall Manager (AFM) support that allows us to configure DNS Profile monitoring, blacklisting malicious IPs, rate limiting, etc.
• Again, set the TTL on the wildcard subdomain higher.

Hope this helps you brainstorm a suitable strategy, especially for AWS Route 53 security best practices, to prevent NXDOMAIN attacks.

References

• https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency/configuring-route53-for-cost-protection-from-nxdomain-attacks.html
• https://aws.amazon.com/route53/pricing/