[DNSOP] ANAME TTL vs GCD
Tony Finch <dot@dotat.at> Tue, 30 October 2018 11:50 UTC
Return-Path: <dot@dotat.at>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADE8F12D4EC for <dnsop@ietfa.amsl.com>; Tue, 30 Oct 2018 04:50:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drCXRk3-2ekU for <dnsop@ietfa.amsl.com>; Tue, 30 Oct 2018 04:50:12 -0700 (PDT)
Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19870126CC7 for <dnsop@ietf.org>; Tue, 30 Oct 2018 04:50:12 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:38742) by ppsw-33.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1gHSXB-000XJj-il (Exim 4.91) for dnsop@ietf.org (return-path <dot@dotat.at>); Tue, 30 Oct 2018 11:50:09 +0000
Date: Tue, 30 Oct 2018 11:50:09 +0000
From: Tony Finch <dot@dotat.at>
To: dnsop@ietf.org
Message-ID: <alpine.DEB.2.20.1810301108050.24450@grey.csi.cam.ac.uk>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/T0lCo5PzVu9mKjjnbWZGMgQkE2Q>
Subject: [DNSOP] ANAME TTL vs GCD
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Oct 2018 11:50:15 -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 <dot@dotat.at> http://dotat.at/ democracy, participation, and the co-operative principle
- [DNSOP] ANAME TTL vs GCD Tony Finch
- Re: [DNSOP] ANAME TTL vs GCD Bjørn Mork
- Re: [DNSOP] ANAME TTL vs GCD Matthijs Mekking
- Re: [DNSOP] ANAME TTL vs GCD Tony Finch
- Re: [DNSOP] ANAME TTL vs GCD Tony Finch