Best Practice TTL Values

DNS uses a time-to-live (TTL) value to determine how long a DNS response can be cached and reused for other DNS queries. Specifically, RFC 1035 states (emphasis mine):

…[TTL is] the time interval that the resource record may be cached before the source of the information should again be consulted.

Which essentially means that the TTL value returned in a DNS query is a recommendation vs. a requirement. Often times cache operators will ignore or modify TTL values that are received in a DNS response (see section 5 of RFC 9499 for an example).

Even though the TTL values you define in your zones may be ignored by cache operators, it is still a good idea to develop a policy around how you set those TTL values. This will help keep your query volumes consistent in your UltraDNS account. Back in the 80's, the guidance was to configure TTL values on the order of days (RFC 1034). Today, there are two driving forces when considering TTL values; how does it impact number of authoritative queries (which equates to cost of running your DNS)?, and how does it impact performance/availability of the resource being pointed to?

Answering the first question is easy, if you want to reduce costs associated with your DNS you will need to increase TTL values. Longer TTL values will stay in recursive caches for longer. If you're not concerned with the cost of your DNS service then you can go as low as you want on those TTL values, assuming you have the infrastructure to support the added load (which you do with UltraDNS).

The second question can be a little harder to answer, and you have think about the flexibility of the data (IP address, canonical name, mail server name, etc.) being pointed to in the DNS. If the data can be updated on the fly, and should be reflected in DNS responses quickly then you'll need lower TTL values. When I setup zones I take a moderate approach between aggressive TTLs values and long living cache entries. Here are some of my recommendations:

Keep TTLs between 300 and 86400 seconds. Anything lower than 300 seconds is going to drive up query volumes while TTLs above 86400 are probably too rigid in most cases. Mission critical applications that have the need and ability to failover quickly would justify TTLs lower than 300 seconds (and would probably be associated with UltraDNS SiteBacker pools).
NS records should be set to 86400. DNS best practices recommends having two or more NS records for your zone for redundancy purposes. UltraDNS platform design decisions such as name server TLD diversity and products such as UltraDNS2 preclude the need to swap out records in the NS RRset so low TTLs provide no added value here and just drive up your query counts.
MX records should be set between 21600 and 43200. Mail server failover is achieved with multiple MX records and their preference values.
CNAME records should have higher TTL values than the records they point to. CNAMEs don't usually change as often as the record they point to. If you have an A record with a 300 second TTL and a CNAME record pointing to that A record then your CNAME record TTL will be >300 seconds.
SOA record TTL & Min Cache values should be high. These values are used to determine the TTL value associated with NXDOMAIN responses (whichever one is smallest) per RFC 2308 (see section 5) which are synthesized in response to a DNS query for a non-existent zone. A value of 86400 is probably reasonable but remember that queries for non-existent zones will have these NXDOMAIN responses cached for that amount of time. If you plan on adding a record for a hostname that is routinely and incorrectly queried, it may take a day for users to see the newly created record.

Hopefully these 5 recommendations can help get your query consumption under control. In the end, DNS management costs and business requirements will determine the policy you put in place for setting TTLs.