On 31 May 2016, Lyndon Nerenberg <[email protected]> wrote:
> > 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, ... ?
For pf there's an easy solution: put the IP in a persistent table,
and have a cron job resolve the name and update the table when the IP
changes. Obviously this only works with rules that can take tables to
begin with, but that's good enough in many situations.
Regards,
Liviu Daia
