Random prefix attack mitigation with Amazon Route 53
This blog post shows how to mitigate a random prefix attack with Amazon Route 53. While such an attack will not have an impact on performance or availability, owners of the corresponding public hosted zone will incur charges for queries to non-existing subdomains or prefixes. These charges can be prevented via the mitigation presented here.
Background
What is a random prefix attack
With a random prefix attack someone sends large amounts of DNS queries to random subdomains (or prefixes) that most likely do not exist (e.g. “b835n0knic.edge-cloud.net, lkxmwdw13n.edge-cloud.net, ul1xx83vyq.edge-cloud.net, …”). Nevertheless these attacks are still connected to your domain, e.g. edge-cloud.net in the above example. Usually the DNS queries to these subdomains or prefixes cannot be cached by DNS resolvers, due to their randomness and that the requests are not repeated. This in return leads to the requests always reaching the authoritative nameservers.
Rate limiting or blocking these requests based on the source address typically introduces a high amount of false positives as these attacks are usually conducted via public resolvers. Therefore these attacks are particularly effective and hard to mitigate.
The impact with Amazon Route 53
In the case of Amazon Route 53 as the authoritative nameserver, owners of the corresponding public hosted zone will not see an impact on performance or availability from random prefix attacks. But as Amazon Route 53 also charges for queries to non-existing subdomains or prefixes, users will incur cost.
Cost model of Amazon Route 53
Having a look at the Amazon Route 53 pricing, you’ll notice that queries for a record that doesn’t exist are charged at the standard rate for queries. Currently this is US$ 0.40 per million queries for the first 1 billion queries / month. Using the AWS Pricing Calculator you can therefore see that e.g. 1 billion queries would incur charges of US$ 400.
It’s interesting and important to have a closer look at the pricing for Alias Queries. You will notice that queries to records where the alias target is an AWS resource other than another Route 53 record are free.
From a cost perspective it would therefore be very beneficial if we could turn any query to a non-existing record into a query for an AWS resource.
Mitigation
For the mitigation of the random prefix attack we want to create an AWS resource that we can safely point any non-existing prefix to. Ideally we want to use a service that can perform an URL redirect in case someone just fat-fingered a valid prefix. For this use case the previous blog post URL Redirect with Amazon CloudFront and Amazon Route 53 can be re-used.
Cloudfront distribution with wildcard name
You can follow the instructions from the previous blog post URL Redirect with Amazon CloudFront and Amazon Route 53, starting at the section CloudFront for URL redirectPermalink.
The only difference is that this time you configure the alternate domain names to be *.edge-cloud.net (See Figure 1).
Everything else can remain the same. Therefore if you already have this CloudFront distribution in place, you can just change the alternate domain name.
Create wildcard record in Route 53
As a next step we need to setup a wildcard Alias record in Route 53. This *.edge-cloud.net record will effectively point to the CloudFront distribution created above.
Create a new Route 53 record, where the record name is “”* (star), the record type is “A”, “Alias” is enabled, _Route traffic to_ is selected as *“Alias to CloudFront distribution” with the above CloudFront distribution selected (See Figure 2).
You can repeat the same step for the record type “AAAA” to enable IPv6 support.
Testing the setup
Now it’s time to test our setup. Let’s perform a DNS query against another random subdomain or records underneath the domain in question. While previously such a query should have returned a “NX Domain” response, we should now see IP addresses for CloudFront.
And indeed that’s what we will see.
ubuntu@ubuntu:~$ dig +short hknk5e69s72d2l31cjuw.edge-cloud.net
65.8.158.5
65.8.158.21
65.8.158.83
65.8.158.100
Therefore any attacker trying to resolve random prefixes would be presented with an IP address for CloudFront. As a reminder: We won’t be charged for that request as it’s an Alias record where the alias target is an AWS resource other than another Route 53 record.
Next let’s see what happens if we enter this random hostname into a browser.
ubuntu@ubuntu:~$ curl -sS -D - https://knk5e69s72d2l31cjuw.edge-cloud.net -o /dev/null
HTTP/2 301
server: CloudFront
date: Mon, 12 Jun 2023 00:10:39 GMT
content-length: 0
location: https://www.edge-cloud.net
x-cache: FunctionGeneratedResponse from cloudfront
via: 1.1 1943af12d816afc5bfe1ce2c8b3de416.cloudfront.net (CloudFront)
x-amz-cf-pop: SFO53-C1
alt-svc: h3=":443"; ma=86400
x-amz-cf-id: kdnl6bTnfVMSNe7uyRSKEqrqk2djdvP4g1y0XRvMkLee4Iauk8j80w==
Just as with the previous blog post URL Redirect with Amazon CloudFront and Amazon Route 53, we are being redirected to the website at https://aws.edge-cloud.net.
Further reduce cost
As you will incur charges for HTTP(S) traffic successfully served by CloudFront, you could also chose to only configure your distribution with common mistake hostnames, such as “ww”, or “wwww”. This reduces the cost in case the attacker combines the DNS random prefix attack with an HTTP(S) based attack.
Summary
This blog post showed you how to mitigate a random prefix attack with Amazon Route 53. While such an attack will not have an impact to performance or availability, owners of the corresponding public hosted zone will incur charges for queries to non-existing subdomains or prefixes. By creating a wildcard CloudFront distribution along with an Amazon Route 53 wildcard record, using this CloudFront distribution as the target, cost for queries to non-existing subdomains or prefixes will be removed.