Does a catch all DNS record is a good practice to reduce queries?

Question

We have a domain with Route 53 as a DNS provider. We have many queries to records that don't exist anymore. I thought it will be a good idea to set a catch all record with high TTL, for example: *.example.com -> 1.1.1.1. It means that all DNS queries without an existing record will have long TTL. The problem is that now when I create a new record and check the propagation with https://www.whatsmydns.net/ some of the servers return 1.1.1.1 and some return the real ip address. Is that a good practice?

Thanks

Answer 1

It is never a good practice to point your DNS records to somebody else's IP addresses without having some sort of agreement with the owner of those addresses.

Moreover having a * record is often not a good idea. Some day you may run into scenarios where you really do need NXDOMAIN responses for some names which gets a bit tricky if a * record is present. Additionally the presence of a * record in your zone means that you could easily lose track of which actual names you have been relying on the * record for. That ultimately means that it can be difficult to replace a * record with individual name records, so you may get stuck with a suboptimal configuration.

Also as you noticed a high TTL means that changes you make take a long time to take effect. That's why the TTL for NXDOMAIN responses (specified through a SOA record) is usually fairly low.

Also a * record may not reduce queries as much as you think. A zone with no * record has an astronomical number of nonexisting names. No recursor is ever going to cache a separate entry for every possible 63 character subdomain. So queries for nonexisting names could produce an endless stream of queries that caching individual names can never reduce.

Another option is to sign your zone with DNSSEC. With the introduction of RFC 8198 DNSSEC allows recursors to respond with NXDOMAIN based on cached entries covering an entire range of names rather than only one name covered by each cached record.

If you are receiving lots of queries for nonexisting names from a recursor that supports RFC 8198, then you can reduce those queries by signing your zone.

Specifically the RFC says this:

If the negative cache of the validating resolver has sufficient information to validate the query, the resolver SHOULD use NSEC, NSEC3, and wildcard records to synthesize answers as described in this document. Otherwise, it MUST fall back to send the query to the authoritative DNS servers.

Answer 2

now when I create a new record and check the propagation

That's not how DNS works. Every single recursive system in operation throughout the internet has to learn about the individual records (barring proof of nonexistence provided by DNSSEC signed zones -- see kasperd's answer), and many of those have limits defined for the maximum TTL that they're willing to honor. The servers also forget this cached information whenever they are restarted. This is an unwinnable war against an internet's worth of recursive systems that in all likelihood outnumber the actual devices requesting your DNS records.

Is that a good practice?

Even if we operate under the assumption that you can use cached data to put a significant dent in what remote systems throughout the internet are asking for, the answer is still no. Many people are unaware of the fact that most recursive DNS implementations cache the non-existence of records in addition to their existence. Instead of feeding DNS servers bogus data that will simply take up more space in DNS caches and confuse the people who are trying to request the resource (because you're telling them to talk to an IP instead of telling them it doesn't exist), you should simply be telling those servers to remember your non-existent records for longer. As kasperd rightly points out, interfering with NXDOMAIN actually prevents recursive systems from determining nonexistence without submitting additional queries.

The negative TTL is controlled by the NEGATIVE field of the TTL, and the TTL of the SOA record itself. The minimum (lesser) of the two values prevails. Kudos to Håkan for the reminder!

example.com.    IN    SOA   ns.example.com. hostmaster.example.com. (
                          2003080800 ; sn = serial number
                          172800     ; ref = refresh = 2d
                          900        ; ret = update retry = 15m
                          1209600    ; ex = expiry = 2w
                          3600       ; nx = nxdomain ttl = 1h
                          )

(sample SOA record borrowed from DNS for Rocket Scientists)

Your effective negative TTL tells remote recursive servers how many seconds they should wait before asking again if a record doesn't exist. The drawback is (unsurprisingly) that you shoot yourself in the foot if your company prematurely starts directing customers to a DNS record before it is actually live. Fortunately you can't shoot yourself in the foot too badly, as most DNS server software ignores very high TTL values (including negative) that are above a maximum that they've defined in their local configuration.

In short, it's almost always best to be honest about a record's nonexistence. Advertise a smaller negative TTL if you want remote servers to remember the non-existence of your data longer, or identify why you get so many stale requests for data and solve the problem at its source. (out of date links, etc.)