What happens when multiple MX records in a DNS name have different TTLs?

Question

I am wondering what happens when a domain name in DNS has multiple MX records with different Times to Live (TTLs)?

For example, what if these are the MX records for example.com?

• TTL = 3 days,         priority = 1, result = mx1-slow.example.com
• TTL = 60 seconds, priority = 1, result = mx1-fast.example.com
• TTL = 1 day,            priority = 2, result = mx2.example.com
• TTL = 1 hour,          priority = 3, result = mx3-hour.example.com
• TTL = 60 seconds, priority = 3, result = mx3-fast.example.com
• TTL = 2 days,         priority = 3, result = mx3-slow.example.com

What happens if a mail transfer agent is sending a message to this domain -- where some of the MX servers might be working and some might not -- and has the results cached for 2 minutes? 2 hours? 1.5 days? 2.5 days? Does it need to go by the smallest TTL across all the MX records (60 seconds in this case) and do a re-lookup of all the MX records if that much time has passed, ignoring the longer TTLs on the remaining MX records? Or does the cache actually take into account all of the different TTLs somehow? If all of the TTLs are taken into account, can you please provide some example scenarios of how this might work?

Answer 1

The scenario that you describe is not a valid record set.

A single RRset (the set of records for a specific name,class,type combination) is not allowed to have differing TTLs for its individual records. However, if such a (invalid) record set is encountered when communicating with an authoritative server the smallest TTL should be used, in other cases the record set should be ignored entirely.

From Clarifications to the DNS Specification (from 1997):

5.2. TTLs of RRs in an RRSet
Resource Records also have a time to live (TTL). It is possible for the RRs in an RRSet to have different TTLs. No uses for this have been found that cannot be better accomplished in other ways. This can, however, cause partial replies (not marked "truncated") from a caching server, where the TTLs for some but not all the RRs in the RRSet have expired.

Consequently the use of differing TTLs in an RRSet is hereby deprecated, the TTLs of all RRs in an RRSet must be the same.

Should a client receive a response containing RRs from an RRSet with differing TTLs, it should treat this as an error. If the RRSet concerned is from a non-authoritative source for this data, the client should simply ignore the RRSet, and if the values were required, seek to acquire them from an authoritative source. Clients that are configured to send all queries to one, or more, particular servers should treat those servers as authoritative for this purpose. Should an authoritative source send such a malformed RRSet, the client should treat the RRs for all purposes as if all TTLs in the RRSet had been set to the value of the lowest TTL in the RRSet. In no case may a server send an RRSet with TTLs not all equal.