[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-misc
Subject:    Re: ntpd tries to connect via ipv6
From:       Lyndon Nerenberg <lyndon () orthanc ! ca>
Date:       2016-05-31 23:47:19
Message-ID: 7BBCF6B8-2F87-4502-8B7C-AC33CA66D4E5 () orthanc ! ca
[Download RAW message or body]

> On May 31, 2016, at 3:58 PM, Ted Unangst <tedu@tedunangst.com> 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, ... ?

[prev in list] [next in list] [prev in thread] [next in thread]