On 16 May 2016, at 10:24, jdebert wrote:
On Mon, 16 May 2016 12:25:10 +0100
Dominic Benson <domi...@lenny.cus.org> wrote:
Accepting that not all ISPs are as helpful as they might be, I can't
easily think of a legitimate reason for needing the TTL on the PTR of
a mail server to be small, so if a blacklist operator finds it an
effective way to manage request volume then that doesn't seem
unreasonable.
Aren't short TTL's also indicative of load balancing and
"cloud" systems? If this is truly the case it would seem a legitimate
practice which makes blacklisting short TTL seems quite unreasonable.
Short TTLs are an indispensable feature of DNS-based load balancing for
email servers, but only on the MX and (sometimes) A records. Short TTLs
on PTR records are not operationally significant because no widely used
standardized protocol depends on PTRs technically. It is possible to get
decent load balancing out of just having multiple short-TTL MX records
of the same weight that never actually change, if you have a DNS server
that randomizes the order of the records it sends in answers so that
senders try them in randomized order (usually...)
"Cloud system" is such a vaguely defined phrase (fitting, I guess...)
that I expect something that someone slaps that label on relies on short
"forward" TTLs, but again there's no concrete reason to make PTRs
short-lived because essentially nothing uses them them. Also, the only
point of short TTLs for cloud systems would be to allow for dynamic IP
assignment, making them entirely reasonable for listing on blacklists of
dynamically assigned IPs.
ISTR that this is an ancient topic and there should be plenty of
archived discussion. (No, I won't research it for you. Sorry.)
It's been discussed in various fora for about 17 years, starting around
when Gordon Fecyk started his DUL DNSBL. As a practical matter, default
TTLs have dropped over time because the reliability of the Internet has
gotten much better and the computers acting as nameservers much more
capable, while the nuisance level of having to reduce a 1-day TTL 2 days
in advance of a DNS change has remained constant.
