Mitigating billing costs for non-existent host names on Route 53

5 days into this billing cycle, and my Route 53 zone has received over 33 million requests for a particular host that I recently deleted. And the associated DNS records were deleted too.

I didn't think I would get billed for queries to a non-existent host record, but indeed I am according to the billing dashboard. And the number of queries has doubled since it was removed. Some initial query logging and investigation suggests that there are clients making many redundant requests for this deleted hostname.

If you're interested, this host was operating as an open public server for the STUN protocol to bootstrap WebRTC and VOIP calls. The billing costs to run this public server were getting out of hand. So I moved it to a new IP address and new host name. I had recently learned of some other well known public services that had hardcoded the DNS address into their code and sample documentation.

Tonight, I added back a bogus A and AAAA record that resolves to 127.0.0.1 (or ::1) with a 4 day TTL. That might make whatever code that's repeating the request to stop asking (as much) and have the entry cached in downstream DNS servers. But excessive and redundant DNS queries has always been a costly problem that I never could get a handle on. I've dealt with and mitigated DDOS attacks on the host service for years, but I've never understood how to firewall Route 53 clients make redundant requests.

The ideal solution would be that Route 53 would simply ignore requests for the deleted host name (and not bill me for it).

What are my options?

Rather than deleting a record your current solution of returning valid response with a localhost IP-address and very long TTL is indeed one solution.

The (current) official documentation from Amazon Route 53 states and suggests an alternative approach

When Route 53 responds to DNS queries with an NXDOMAIN or NODATA response (a negative response), you're charged the rate for standard queries. (See "Queries" in Amazon Route 53 Pricing). If you're concerned about the cost of negative responses:

• Increase the TTL value of the SOA record (which is set to 900 seconds by default)

• Increase the value minimum time to live (TTL) value (86400 seconds (= 24 hours) by default) in the SOA record

That should increase the amount of time that a DNS response from Route 53 that a particular DNS record does not exist, a NXDOMAIN and/or NODATA response will be cached (in proper resolvers that support negative caching). That should reduce the number of requests that you're billed for.

A SOA record includes the following elements:

The minimum time to live (TTL). This value helps define the length of time that recursive resolvers should cache the following responses from Route 53:

• NXDOMAIN There is no record of any type with the name that is specified in the DNS query, such as example.com. There also are no records that are children of the name that is specified in the DNS query, such as zenith.example.com.

• NODATA There is at least one record with the name that is specified in the DNS query, but none of those records have the type (such as A) that is specified in the DNS query.

When a DNS resolver caches an NXDOMAIN or NODATA response, this is referred to as negative caching.

The duration of negative caching is the lesser of the following values:

• This value—the minimum TTL in the SOA record. In the example, the value is 86400 (one day).
• The value of the TTL for the SOA record.

When Route 53 responds to DNS queries with an NXDOMAIN or NODATA response (a negative response), you're charged the rate for standard queries. (See "Queries" in Amazon Route 53 Pricing). If you're concerned about the cost of negative responses, one option is to change the TTL for the SOA record, the minimum TTL in the SOA record (this value), or both. Note that increasing these TTLs, which apply to negative responses for the entire hosted zone, can have both positive and negative effects:

...