> On May 31, 2016, at 3:58 PM, Ted Unangst <[email protected]> wrote: > > If we're talking about timeframes long enough for network connectivity to come > and go, that's long enough for IP addresses to come and go as well.
This is an interesting problem, in general. In my MTA development days, we would cache the targets of the MX record(s) we found in queued message's metadata. For each host target, we included the absolute time the data would expire, based on the original MX lookup. Expired records were ignored, and when we ran out of hosts we would re-run the MX lookup and update the meta-data. This worked quite well, considering the underlying DNS data didn't change all that often. But SMTP sessions are not long-lived, so this just worked. These days I wish I had similar functionality in pf. And not for mobile hosts. E.g., at work we need to open up access to things like Paypal payment API hosts. For those rules we can either hardwire IP addresses, or use their hostnames. But they inevitably move their API hosts around. In the first case, our list of hardwired IP addresses gets stale. In the second, the addresses returned by the A(AAA) record lookup gets stale. I would really like to be able to say "build the rule from this hostname, but refresh the A(AAA) record results as the underlying data's TTL expires." pf isn't special - this is the same problem as the ntpd example. I've puzzled over how to deal with this, but I can't see a solution that doesn't involve some sort of proxy that isolates the process from the network changes. And even then, you're dealing with at least a TCP connection reset if an existing address vanishes. For some things, that's not an issue. For others, ... ?
