[DNSOP] ANAME TTL vs GCD

[Tony Finch <[e-mail]>]

One of the more complicated aspects of ANAME is working out how TTLs
should work, because there are a bunch of tricky constraints. There's
a fairly long rationale in an appendix about the various issues -
https://tools.ietf.org/html/draft-ietf-dnsop-aname-02#appendix-D

As a design guideline (to help decide choices) I have tried to make ANAME
"like CNAME but only for address records", as much as possible.

So, the current spec says that the TTL of the sibling address records is
the least TTL from the chain of ANAME and CNAME records and the ultimate
target address records. This tries to match the implicit TTL of a CNAME
chain, which is a result of the chain being followed each time on demand,
so the earliest time the result can change is when the record with the
least TTL changes.

As a zone administrator, I prefer not having to care about TTLs too much,
so I prefer the ANAME mechanism to do the sensible thing without
hand-holding. I had a suggestion (from Matthijs Mekking I think?) of just
using the ANAME's TTL to set the TTL of the sibling address records, but
for the zones I look after, this would require a lot of special-case TTLs
and annoying manual work.

However, I just realised the currently specified "least TTL" logic is
going to have interesting effects when the greatest common divisor of the
TTLs is less than the least TTL, when the ANAME processor is querying via
a resolver cache that is outside its control.

e.g. consider what happens when there is an ANAME with TTL 30s and target
address records with TTL 45s.

In the first round, the ANAME processor will choose a 30s TTL.

In the second round, 30s later, it will get the target address records
from the cache with a 15s TTL, so it'll choose a 15s TTL.

The in the third round it'll be back to 30s.

The TTL will flip-flop, and there will be a lot of unwanted zone updates.

This is ugly :-( I'm not sure what the best solution is.

One possibility is to make the ANAME processor keep a bit more state. At
the moment its nearly-stateless algorithm naturally sees through caches to
converges on the target's authoritative TTL, because it re-checks after
the cache expires. If instead it explicitly tracks the TTLs of each link
in the ANAME+CNAME chain and deliberately works out the authoritative
TTLs, then it can avoid the GCD flip-flop. But it would makes the algorihm
and spec quite a lot more complicated, though I think I prefer that to
manual hand-holding...

Tony.
-- 
f.anthony.n.finch  <[e-mail]>  http://dotat.at/
democracy, participation, and the co-operative principle