IETF Logo Mail Archive

Re: [DNSOP] Minimum viable ANAME

Tony Finch <dot@dotat.at> Tue, 26 March 2019 16:10 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 ECFEA12053D for <dnsop@ietfa.amsl.com>; Tue, 26 Mar 2019 09:10:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PqqyxNwd96Aq for <dnsop@ietfa.amsl.com>; Tue, 26 Mar 2019 09:10:05 -0700 (PDT)
Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [131.111.8.142]) (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 434B712052F for <dnsop@ietf.org>; Tue, 26 Mar 2019 09:10:05 -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]:36130) by ppsw-42.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1h8oeJ-000P30-8N (Exim 4.91) (return-path <dot@dotat.at>); Tue, 26 Mar 2019 16:10:03 +0000
Date: Tue, 26 Mar 2019 16:10:03 +0000
From: Tony Finch <dot@dotat.at>
To: Matthijs Mekking <matthijs@pletterpet.nl>
cc: dnsop@ietf.org
In-Reply-To: <104ec4ea-296f-1657-5633-f6c1f2684274@pletterpet.nl>
Message-ID: <alpine.DEB.2.20.1903261540330.13313@grey.csi.cam.ac.uk>
References: <20180919201401.8E0C220051382A@ary.qy> <08C8A740-D09B-4577-AF2A-79225EDB526B@dotat.at> <20180920061343.GA754@jurassic> <E944887D-51ED-41A0-AC5A-3076743620D8@isoc.org> <acef1f69-8e4f-52cc-dca5-3ada9446e0ee@bellis.me.uk> <CABrJZ5HmCoSsGe2L-JkAsPywhcxyyVkvMmXCvQyJMjWHnMeT_w@mail.gmail.com> <alpine.DEB.2.20.1903261521290.13313@grey.csi.cam.ac.uk> <104ec4ea-296f-1657-5633-f6c1f2684274@pletterpet.nl>
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/CLl3OR2m7ive5pyD-wK8Ca4x3Ig>
Subject: Re: [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: Tue, 26 Mar 2019 16:10:07 -0000

Matthijs Mekking <matthijs@pletterpet.nl> wrote:
>
> I think that would be the wrong direction.  I believe there is a need to
> standardize the ANAME resolution process and so my suggestion would be to
> reduce the scope by focusing just on how to do that on the provisioning side
> (and leave secondary servers and resolvers out of scope for now).

>From past discussions, I didn't think there was any way we could get
consensus on the provisioning side.

Dynamic lookups on authoritative servers are out, because it has to be
compatible with traditional secondaries.

Updates on the primary are out, because that doesn't scale to large
numbers of zones.

Sometimes a system might have known fallback addresses, but often it won't
(e.g. whether the DNS setup is or isn't coupled to a web provisioning
system).

But I think it's reasonable to allow whatever provisioning mechanisms
there might be, provided the meaning of answers from auth -> rec have a
consistent meaning that resolvers can use.

It's also really imortant that ANAME can work in multi-provider setups, so
there needs to be something approaching interoperable semantics for
importing a zone file into a provisioning system. (Though I think the
semantics will have to be very loose in this case, to allow for variations
between existing systems.)

I haven't seen any objections to support for ANAME in recursive servers
so I'm surprised you think that is problematic enough to be removed. My
understanding was that recursive support is seen as better than trying to
do all the tricks on authoritative servers.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
safeguard the balance of nature and the environment

v2.23.0 | Report a Bug | By Email