Re: [DNSOP] ANAME TTL vs GCD

[Matthijs Mekking <[e-mail]>]

I am still of the opinion that the expanded A and AAAA records should 
use the ANAME TTL*, and the target TTL should be ignored. That TTL is 
only useful for the cache that is used as part of the ANAME expansion 
process.


The ANAME TTL may be subject to decreasing, if sibling A and AAAA 
records already exist with a lower TTL.

Best regards,
   Matthijs



On 30-10-18 12:50, Tony Finch wrote:
> 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.
>