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 <d...@dotat.at> http://dotat.at/ democracy, participation, and the co-operative principle _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
