After some thought, a reasonable way to address this issue is probably:
* Require the sibling address record TTL to be less than the minimum TTL
of the ANAME/CNAME chain (plus some slop so that the polling does not
have to be too frequent), without specifying any particular algorithm.
* Describe the GCD issue, probably in an operational considerations
section (the TTL appendix is supposed to be just rationale)
A reasonable way to address it in practice is to turn our adversary into
our ally:
* When scanning the ANAME/CNAME chain, round each TTL to a multiple of
your minimum polling interval (round up, so that your next poll is
just after the TTL expires, not just before)
* Use the GCD of the rounded TTLs to set the TTL of the sibling address
records. This will typically be the same as the minimum TTL, but it
will avoid flip-flopping in awkward cases.
The reason to discuss this in an operational considerations section is
to warn about pointing an ANAME processor at multiple caches, because that
makes it much harder to get a stable TTL for the sibling address records.
It's too early to tell how much of a problem this will be in practice and
therefore how much effort is needed to deal with it...
Tony.
--
f.anthony.n.finch <[email protected]> http://dotat.at/
Sole: Variable 4, becoming northeasterly 4 or 5 for a time, becoming southerly
4 or 5 later, occasionally 6 in west. Moderate or rough. Rain or showers. Good
occasionally poor.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
