[DNSOP] Minimum viable ANAME
Tony Finch <dot@dotat.at> Wed, 19 September 2018 13:55 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 1675413107E for <dnsop@ietfa.amsl.com>; Wed, 19 Sep 2018 06:55:50 -0700 (PDT)
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 v82vCv4fXOuf for <dnsop@ietfa.amsl.com>; Wed, 19 Sep 2018 06:55:47 -0700 (PDT)
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 0B97513107D for <dnsop@ietf.org>; Wed, 19 Sep 2018 06:55:47 -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]:55544) 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 1g2cxF-000YvE-eA (Exim 4.91) for dnsop@ietf.org (return-path <dot@dotat.at>); Wed, 19 Sep 2018 14:55:45 +0100
Date: Wed, 19 Sep 2018 14:55:45 +0100
From: Tony Finch <dot@dotat.at>
To: dnsop@ietf.org
Message-ID: <alpine.DEB.2.20.1809191455190.3596@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/LrQ0LRVXkLYhs_phM6O7b2VY8pQ>
Subject: [DNSOP] Minimum viable ANAME
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: Wed, 19 Sep 2018 13:55:57 -0000
I think there's still a need to standardize ANAME, to provide at least some level of zone file portability between the various existing proprietary versions of this feature. And to provide something usable by zone publisters on a much shorter timescale than a nsa SRV-alike. So here's a sketch of a reduced ANAME: Primary servers / zone provisioning ----------------------------------- For each ANAME record, poll the target address records periodically (according to the relevant TTLs). When the target addresses don't match the owner's addresses, UPDATE the zone so they match. Authoritative servers / zone transfers -------------------------------------- No special new behaviour. Additional section processing ----------------------------- This applies to auth and rec servers. In response to an A / AAAA / ANAME query, include any sibling A / AAAA / ANAME records, and any ANAME target A / AAAA records. When DO=1, include DNSSEC proofs of nonexistence for missing RRsets. As usual for additional section processing, you don't have to include records that aren't available, so (for instance) auth servers don't have to include out-of-zone data in the response. Recursive servers ----------------- When responding to a query with DO=0 or when the ANAME owner's zone is unsigned, a recursive server can substitute the target addresses in place of the owner's addresses. Rationale --------- The primary server behaviour is an "as if" description: that's what it looks like for the purpose of interop with secondary servers and zone files. There doesn't seem to be any point in making secondary servers do anything: their view of the target address records will be just as wrong or right as the primary server's. Zone publishers that want clever auth servers will use some kind of multi-headed CDN distributed stunt DNS server, and we aren't going to standardize that. Putting cleverness in resolvers compensates for the lack of cleverness in secondary servers. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Hebrides: Cyclonic 5 to 7 becoming west or southwest 7 to severe gale 9. Rough or very rough becoming very rough or high. Showers. Good, occasionally poor.
- [DNSOP] Minimum viable ANAME Tony Finch
- Re: [DNSOP] Minimum viable ANAME Anthony Eden
- Re: [DNSOP] Minimum viable ANAME Tony Finch
- Re: [DNSOP] Minimum viable ANAME Paul Vixie
- Re: [DNSOP] Minimum viable ANAME Paul Wouters
- Re: [DNSOP] Minimum viable ANAME Tony Finch
- Re: [DNSOP] Minimum viable ANAME John Levine
- Re: [DNSOP] Minimum viable ANAME Tony Finch
- Re: [DNSOP] Minimum viable ANAME Paul Wouters
- Re: [DNSOP] Minimum viable ANAME Mukund Sivaraman
- Re: [DNSOP] Minimum viable ANAME Tony Finch
- Re: [DNSOP] Minimum viable ANAME Tony Finch
- Re: [DNSOP] Minimum viable ANAME 神明達哉
- Re: [DNSOP] Minimum viable ANAME Tony Finch
- Re: [DNSOP] Minimum viable ANAME Dan York
- Re: [DNSOP] Minimum viable ANAME Matthew Pounsett
- Re: [DNSOP] Minimum viable ANAME 神明達哉
- Re: [DNSOP] Minimum viable ANAME JW
- Re: [DNSOP] Minimum viable ANAME Ray Bellis
- Re: [DNSOP] Minimum viable ANAME Havard Eidnes
- Re: [DNSOP] Minimum viable ANAME Tony Finch
- Re: [DNSOP] Minimum viable ANAME Havard Eidnes
- Re: [DNSOP] Minimum viable ANAME Tim Wicinski
- Re: [DNSOP] Minimum viable ANAME Tony Finch
- Re: [DNSOP] Minimum viable ANAME Havard Eidnes
- Re: [DNSOP] Minimum viable ANAME Ray Bellis
- Re: [DNSOP] Minimum viable ANAME Erik Nygren
- Re: [DNSOP] Minimum viable ANAME Paul Vixie
- Re: [DNSOP] Minimum viable ANAME Ray Bellis
- Re: [DNSOP] Minimum viable ANAME Ray Bellis
- Re: [DNSOP] Minimum viable ANAME Paul Vixie
- Re: [DNSOP] Minimum viable ANAME Mark Andrews
- Re: [DNSOP] Minimum viable ANAME Paul Vixie
- Re: [DNSOP] Minimum viable ANAME Mark Andrews
- Re: [DNSOP] Minimum viable ANAME Brian Dickson
- Re: [DNSOP] Minimum viable ANAME Ray Bellis
- Re: [DNSOP] Minimum viable ANAME Tim Wicinski
- Re: [DNSOP] Minimum viable ANAME Paul Vixie
- Re: [DNSOP] Minimum viable ANAME Ben Schwartz
- Re: [DNSOP] Minimum viable ANAME Matthijs Mekking
- Re: [DNSOP] Minimum viable ANAME Ray Bellis
- Re: [DNSOP] Minimum viable ANAME Tim Wicinski
- Re: [DNSOP] Minimum viable ANAME Ray Bellis
- Re: [DNSOP] Minimum viable ANAME Matthijs Mekking
- Re: [DNSOP] Minimum viable ANAME Ray Bellis
- Re: [DNSOP] Minimum viable ANAME Matthijs Mekking
- Re: [DNSOP] Minimum viable ANAME Mark Andrews
- Re: [DNSOP] Minimum viable ANAME Mark Andrews
- Re: [DNSOP] Minimum viable ANAME Ben Schwartz
- Re: [DNSOP] Minimum viable ANAME Mark Andrews
- [DNSOP] ALTSRV Masataka Ohta
- Re: [DNSOP] Minimum viable ANAME Ben Schwartz
- Re: [DNSOP] Minimum viable ANAME Mark Andrews
- Re: [DNSOP] Minimum viable ANAME Olli Vanhoja
- Re: [DNSOP] Minimum viable ANAME tjw ietf
- Re: [DNSOP] Minimum viable ANAME Dan York
- Re: [DNSOP] Minimum viable ANAME Tony Finch
- Re: [DNSOP] Minimum viable ANAME Matthijs Mekking
- Re: [DNSOP] Minimum viable ANAME Matthijs Mekking
- Re: [DNSOP] Minimum viable ANAME Matthijs Mekking
- Re: [DNSOP] Minimum viable ANAME Tony Finch
- Re: [DNSOP] Minimum viable ANAME Tony Finch
- Re: [DNSOP] Minimum viable ANAME Brian Dickson
- Re: [DNSOP] Minimum viable ANAME Matthijs Mekking
- Re: [DNSOP] Minimum viable ANAME Vladimír Čunát
- Re: [DNSOP] Minimum viable ANAME Olli Vanhoja
- Re: [DNSOP] Minimum viable ANAME Vladimír Čunát
- Re: [DNSOP] Minimum viable ANAME Brian Dickson
- Re: [DNSOP] Minimum viable ANAME Olli Vanhoja
- Re: [DNSOP] Minimum viable ANAME Brian Dickson
- Re: [DNSOP] Minimum viable ANAME Olli Vanhoja
- Re: [DNSOP] Minimum viable ANAME Tony Finch
- Re: [DNSOP] Minimum viable ANAME Dan York
- Re: [DNSOP] Minimum viable ANAME Benno Overeinder