Re: [DNSOP] Fundamental ANAME problems
Tony Finch <dot@dotat.at> Fri, 09 November 2018 16:39 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 CF7CF129BBF for <dnsop@ietfa.amsl.com>; Fri, 9 Nov 2018 08:39:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.641
X-Spam-Level:
X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, TVD_PH_BODY_META=1.559] 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 1MJykt1lL_RI for <dnsop@ietfa.amsl.com>; Fri, 9 Nov 2018 08:39:35 -0800 (PST)
Received: from ppsw-31.csi.cam.ac.uk (ppsw-31.csi.cam.ac.uk [131.111.8.131]) (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 C92B31286D9 for <dnsop@ietf.org>; Fri, 9 Nov 2018 08:39:35 -0800 (PST)
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]:55448) by ppsw-31.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1gL9oj-000DhV-Kg (Exim 4.91) (return-path <dot@dotat.at>); Fri, 09 Nov 2018 16:39:33 +0000
Date: Fri, 09 Nov 2018 16:39:33 +0000
From: Tony Finch <dot@dotat.at>
To: Richard Gibson <richard.j.gibson@oracle.com>
cc: IETF DNSOP WG <dnsop@ietf.org>
In-Reply-To: <f78934dc-bb05-a9b8-da81-6e610346c827@oracle.com>
Message-ID: <alpine.DEB.2.20.1811091533160.3596@grey.csi.cam.ac.uk>
References: <CAH1iCirXYsYB3sAo8f1Jy-q4meLmQAPSFO-7x5idDufdT_unXQ@mail.gmail.com> <CA+nkc8C6yVT62cW5QP-ec2ZT7FY_n48Ecr=CLeE6FS_1duBO8g@mail.gmail.com> <bccfabab-6fab-867e-7c12-8ced9f0d11b6@oracle.com> <f78934dc-bb05-a9b8-da81-6e610346c827@oracle.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="1870870841-1116726980-1541779218=:3596"
Content-ID: <alpine.DEB.2.20.1811091601130.3596@grey.csi.cam.ac.uk>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/r440UJ4f4DdmBN0SXQjwOQYGd34>
Subject: Re: [DNSOP] Fundamental ANAME problems
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: Fri, 09 Nov 2018 16:39:38 -0000
Richard Gibson <richard.j.gibson@oracle.com> wrote: > > First, I am troubled by the requirement that ANAME forces the zone into a > dynamic zone. I don't see how it is possible to implement ANAME without some form of dymamic behaviour, either by UPDATEs on the primary, or on-demand substitution on the secondaries, or some combination of the two. > Second, and relatedly, I think the TTLs of replacement records established for > non-transfer responses are too high. Respecting the TTL of every record in a > chain that starts with the ANAME requires the TTL of final replacement records > to be no higher than the minimum TTL encountered over the chain, potentially > /reduced/ nondeterministically to mitigate query bunching. I would therefore > add language encouraging resolvers synthesizing those records to engage in > best-effort determination of original TTLs by (e.g., by directly querying > authoritative servers and refreshing at 50% remaining), but *requiring* them > to decrement TTLs of records for which they are not authoritative. I'm not sure I understand which TTLs you are worried about here. What are "non-transfer responses"? There's certainly some rewording needed to make it more clear, but the TTLs returned by resolvers that do sibling address record substitution are decremented in the usual way, and resolvers make no attempt to determine the original TTLs. It isn't possible to require a resolver to query authoritative servers directly. > And finally, back on the question of what ANAME sibling address records > actually represent, I think that NXDOMAIN and NODATA results should be treated > as errors for the purposes of ANAME sibling replacement. This position can be > justified on both practical and principled grounds—replacing functional > records with an empty RRSet is undesirable for DNS users (or at least the > sample of them that are Oracle+Dyn customers), Maybe so, but that's what happens with CNAME records. > and could inappropriately stretch the maximum specified ANAME sibling > TTL (on the ANAME record itself) to the SOA MINIMUM value (which is > doubly bad, because it results in extended caching of the /least/ > valuable state). That's a very good point, thank you. > Let's please just eliminate all of that by specifying that ANAME > processing can never replace something with nothing. So when the target goes away, you would prefer to leave behind zombie address records, and stretch their TTL indefinitely? If the zone admin is given only a target hostname (just like a CNAME) they don't have any alternative addresses to use when the target goes away. So the options are to copy the target by deleting the addresses, or ignore the target and leave the addresses to rot. I'm inclined to say that fallback records should remain a non-standard feature. The semantics can be that when you see the target go AWOL, delete the ANAME and its siblings, and replace them with the fallback records that were specified by some other means. You can apply the same logic to CNAMEs too, if you want :-) > P.S. There is a typographical error in Appendix D; "RRGIG" should be "RRSIG". Thanks. > P.P.S. I think it has been discussed before, but this document should also > introduce and use a new "Address RTYPE" registry or subregistry, rather than > forever constraining ANAME exclusively to A and AAAA. The -01 draft specified a registry but I dropped that from -02 because I was not sure if it should include X25, ISDN, NSAP, ATMA, the ILNP types, the Nimrod types, etc. And now I realise that it needs a lot more thought about what will happen to interoperability when the registry changes. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ a fair, free and open society
- [DNSOP] Fundamental ANAME problems Brian Dickson
- Re: [DNSOP] Fundamental ANAME problems John Levine
- Re: [DNSOP] Fundamental ANAME problems Brian Dickson
- Re: [DNSOP] Fundamental ANAME problems John R Levine
- Re: [DNSOP] Fundamental ANAME problems Paul Vixie
- Re: [DNSOP] Fundamental ANAME problems Matthijs Mekking
- Re: [DNSOP] Fundamental ANAME problems Tony Finch
- Re: [DNSOP] Fundamental ANAME problems Måns Nilsson
- Re: [DNSOP] Fundamental ANAME problems Erik Nygren
- Re: [DNSOP] Fundamental ANAME problems Bob Harold
- Re: [DNSOP] Fundamental ANAME problems Richard Gibson
- Re: [DNSOP] Fundamental ANAME problems Paul Vixie
- Re: [DNSOP] Fundamental ANAME problems Christian Huitema
- Re: [DNSOP] Fundamental ANAME problems John R Levine
- Re: [DNSOP] Fundamental ANAME problems Lanlan Pan
- Re: [DNSOP] Fundamental ANAME problems Joe Abley
- Re: [DNSOP] Fundamental ANAME problems Måns Nilsson
- Re: [DNSOP] Fundamental ANAME problems Patrik Fältström
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Paul Vixie
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Brian Dickson
- Re: [DNSOP] Fundamental ANAME problems Patrik Fältström
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Paul Ebersman
- Re: [DNSOP] Fundamental ANAME problems Paul Ebersman
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- [DNSOP] CNAME at apex - a website publisher persp… Dan York
- Re: [DNSOP] Fundamental ANAME problems Måns Nilsson
- Re: [DNSOP] Fundamental ANAME problems Joe Abley
- Re: [DNSOP] Fundamental ANAME problems manu tman
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Paul Ebersman
- Re: [DNSOP] Fundamental ANAME problems Jim Reid
- Re: [DNSOP] Fundamental ANAME problems Paul Vixie
- Re: [DNSOP] Fundamental ANAME problems Paul Vixie
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Paul Vixie
- Re: [DNSOP] Fundamental ANAME problems Mark Andrews
- Re: [DNSOP] Fundamental ANAME problems Tony Finch
- Re: [DNSOP] Fundamental ANAME problems Mark Andrews
- Re: [DNSOP] Fundamental ANAME problems Patrik Fältström
- Re: [DNSOP] Fundamental ANAME problems Joe Abley
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Olli Vanhoja
- Re: [DNSOP] Fundamental ANAME problems Thomas Peterson
- Re: [DNSOP] Fundamental ANAME problems Tony Finch
- Re: [DNSOP] Fundamental ANAME problems Joe Abley
- Re: [DNSOP] Fundamental ANAME problems Patrik Fältström
- Re: [DNSOP] Fundamental ANAME problems Dan York
- [DNSOP] Further ANAME minimization /\ Ray converg… Tony Finch
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Tony Finch
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Ray Bellis
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Tony Finch
- Re: [DNSOP] Fundamental ANAME problems Patrik Fältström
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Matthijs Mekking
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Richard Gibson
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Tim Wicinski
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Ray Bellis
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Michael J. Sheldon
- Re: [DNSOP] Further ANAME minimization /\ Ray con… tjw ietf
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Kevin Darcy
- Re: [DNSOP] Fundamental ANAME problems Richard Gibson
- Re: [DNSOP] Fundamental ANAME problems Matthijs Mekking
- Re: [DNSOP] Fundamental ANAME problems Tim Wicinski
- Re: [DNSOP] Fundamental ANAME problems Tony Finch
- Re: [DNSOP] Fundamental ANAME problems Bob Harold
- Re: [DNSOP] Fundamental ANAME problems Richard Gibson
- Re: [DNSOP] Fundamental ANAME problems Matthijs Mekking
- Re: [DNSOP] Fundamental ANAME problems Thomas Peterson
- Re: [DNSOP] Fundamental ANAME problems Tim Wicinski