Subject: [DNSOP] ANAME TTL vs GCD

From: Tony Finch <[email-masked]>
Date: Tue, 30 Oct 2018 11:50:09 +0000

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  <[email-masked]>  http://dotat.at/
democracy, participation, and the co-operative principle

---

From: Bjørn Mork <[email-masked]>
Date: Tue, 30 Oct 2018 12:57:46 +0100

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

Require DNSSEC for ANAME support and use the Original TTL field from the
RRSIG records.

Bjørn

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 30 Oct 2018 14:25:28 +0100

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

---

From: Tony Finch <[email-masked]>
Date: Tue, 30 Oct 2018 13:26:32 +0000

Bjørn Mork <[email-masked]> wrote:
>
> Require DNSSEC for ANAME support

That isn't going to be feasible, I'm afraid, because the tricky TTLs are
down the ANAME+CNAME chain, so they aren't under the control of the ANAME
owner. And many of the use cases for ANAME involve pointing it at targets
that don't do DNSSEC.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Faeroes, Southeast Iceland: Cyclonic, mainly southeasterly, 6 to gale 8. Rough
or very rough. Rain or showers. Good, occasionally poor.