JL> But wait, I hear critics cry: Doesn't that double the number of
JL> lookups someone has to do?
To which the correct answer would have been "Yes. But in the real world
with the way that DNS lookups actually operate the situation isn't quite
as simple as that; and in any case, other factors - such as EDNS0, the
presence of other resource record sets making fallback to DNS/TCP more
likely, and the presence of SMTP Relay clients performing their
"ANY"/"CNAME"/"MX" lookups via the same proxy DNS servers - intervene to
further complicate matters."
JL> Yes, it does. But the large, complicated domains that have this issue
JL> are almost exactly the ones that send lots of legitimate mail. As such,
JL> their records will usually already be in your resolver's DNS cache.
JL> (Said differently, it doesn't matter how complicated AOL's records are,
JL> because your DNS cache will only fetch them once a week.)
The paraphrase is false, for two reasons.
First: The TTL of the resource record set will affect how often they are
fetched. The existing "TXT" resource record set for "aol.com." has a
TTL of 300 seconds, meaning that it will be fetched _at least_ once
every 5 minutes by a caching proxy DNS server.
Second: Most caching proxy DNS servers place a maximum upper bound on
resource record set TTLs. However, not all caching proxy DNS servers
use the _same_ upper bound, and even then it is configurable in many.
(e.g. ISC's BIND has a default upper bound of 7 days, which is
configurable with the "max-cache-ttl" option in its configuration file.
Dan Bernstein's "dnscache" has a fixed non-configurable upper bound of
7 days. Microsoft's DNS server has a default upper bound of 1 day,
which is configurable with the "MaxCacheTTL" value in the registry.)