[DNSOP] Further ANAME minimization /\ Ray convergence
Tony Finch <dot@dotat.at> Tue, 06 November 2018 17:29 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 BFDD4130DFA for <dnsop@ietfa.amsl.com>; Tue, 6 Nov 2018 09:29:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] 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 21gaE7xp5ALk for <dnsop@ietfa.amsl.com>; Tue, 6 Nov 2018 09:29:01 -0800 (PST)
Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 9D6F6130DF3 for <dnsop@ietf.org>; Tue, 6 Nov 2018 09:29:01 -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]:53154) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1gK59v-0004Kt-fF (Exim 4.91) (return-path <dot@dotat.at>); Tue, 06 Nov 2018 17:28:59 +0000
Date: Tue, 06 Nov 2018 17:28:59 +0000
From: Tony Finch <dot@dotat.at>
To: IETF DNSOP WG <dnsop@ietf.org>
cc: Bob Harold <rharolde@umich.edu>, Brian Dickson <brian.peter.dickson@gmail.com>, Richard Gibson <richard.j.gibson@oracle.com>
In-Reply-To: <bccfabab-6fab-867e-7c12-8ced9f0d11b6@oracle.com>
Message-ID: <alpine.DEB.2.20.1811061537410.24450@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>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="1870870841-1248965255-1541520175=:24450"
Content-ID: <alpine.DEB.2.20.1811061720560.24450@grey.csi.cam.ac.uk>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/HGld_NMA0kKzcX3r8sNZiayVJRY>
Subject: [DNSOP] Further ANAME minimization /\ Ray convergence
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, 06 Nov 2018 17:29:04 -0000
I'm going to use Richard's message as a starting point because I wanted to write about fallback addresses, but I have kind of changed my mind so this message is really about the possibility of deeper reductions / revisions to the ANAME draft. Richard Gibson <richard.j.gibson@oracle.com> wrote: > On 11/2/18 15:20, Bob Harold wrote: > > Another option to give users is a non-updating fallback A record, that could > > point to a web redirect. That saves all the hassle of updates. > > YES! This means a slightly worse fallback-only experience for users behind > ANAME-ignorant resolvers that query against ANAME-ignorant authoritatives (the > introduction of ANAME awareness to /either/ component allowing an opportunity > to provide better address records by chasing the ANAME target), but provides a > dramatic reduction in the amount of necessary XFR traffic. And even more > importantly, it forces TTL stretching to be an explicit decision on the part > of those administrators who choose to perform manual target resolution and > update their zones to use them as fallback records (as they would do now to > approximate ANAME anyway), rather than an inherent and enduring aspect of the > functionality. > > Treating ANAME-sibling address records as fallback data also supports better > behavior for dealing with negative results from resolving ANAME targets > (NODATA, NXDOMAIN, signature verification failure, response timeout, > etc.)—serve the fallbacks. Matthijs Mekking has tried hard to persuade me of the merits of fallback addresses, but I didn't really like the idea for a couple of reasons: * They break the elevator pitch, "like CNAME but only for address records" because fallback addresses aren't a thing that CNAMEs have. * With the UPDATE semantics there isn't anywhere for the fallback records to belong. But thinking about the discussions from the weekend and yesterday, it occurs to me that it might make sense to simplify ANAME even further: * Make all authoritative processing optional, whether UPDATE style or dynamic on-demand. * The sibling address records have to be provisioned, to act as fallback records for clients/resolvers that don't (yet) do their own ANAME processing. (There may be some automated assistance.) I'm not entirely comfortable leaving so much unspecified, but it has some advangates: * It's maybe still enough of a spec to provide the zone file portability that a lot of people want * It can fit both the Oracle/Dyn model or my UPDATE model with only a moderate amount of straining * It might work with the nay-sayers, who can continue doing their vertically-integrated thing to provision the address records * It won't give mass domain hosters indigestion from high UPDATE frequency * It doesn't require static authoritative servers to become dynamic The result is getting weirdly close to the HTTP record proposal, though there are still significant differences: * Target address records fetches in the resolver vs in the application * Authoritative support optional vs not present * General purpose (also works for ssh, databases, etc) vs HTTP-specific So I'm wondering, Does it make sense to strip ANAME back this far? Is ANAME/HTTP convergence a useful accident or a foolish distraction? Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Humber, Thames, Dover: South 5, increasing 6 or 7, perhaps gale 8 later. Slight or moderate, occasionally rough later. Rain later. Good, occasionally moderate later.
- [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