Re: [DNSOP] Minimum viable ANAME

Matthijs Mekking <matthijs@pletterpet.nl> Tue, 26 March 2019 16:27 UTC

Return-Path: <matthijs@pletterpet.nl>
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 CC008120491 for <dnsop@ietfa.amsl.com>; Tue, 26 Mar 2019 09:27:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 grhkcXBLZA4C for <dnsop@ietfa.amsl.com>; Tue, 26 Mar 2019 09:27:10 -0700 (PDT)
Received: from lb1-smtp-cloud8.xs4all.net (lb1-smtp-cloud8.xs4all.net [194.109.24.21]) (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 9B26B120457 for <dnsop@ietf.org>; Tue, 26 Mar 2019 09:27:09 -0700 (PDT)
Received: from [192.168.1.19] ([86.49.18.67]) by smtp-cloud8.xs4all.net with ESMTPA id 8oumh68yzUjKf8ouphmFzk; Tue, 26 Mar 2019 17:27:07 +0100
To: dnsop@ietf.org
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> <alpine.DEB.2.20.1903261540330.13313@grey.csi.cam.ac.uk>
From: Matthijs Mekking <matthijs@pletterpet.nl>
Message-ID: <ccf03ce9-32d3-71d6-fa2b-97d906416ccf@pletterpet.nl>
Date: Tue, 26 Mar 2019 17:27:04 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.20.1903261540330.13313@grey.csi.cam.ac.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfC6Z/spGT/bHm9uJohw8zpx30UMVln6dk/sMDGRR8ITWKpCjOI115kaPFpB+ZcEvn/tqDUbdDYcAgcfvJt3EArNTjYjXDgIOnRdGuGWFibTX1cxKCdKE X4hBaGCjZU02BCT7+dPJeNwMVcDXEvFHFasLcw7mzUx2t8oKYwx2fNOq
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/k8EN6vneVchpSxvb0775FSJ99OY>
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:27:12 -0000


On 3/26/19 5:10 PM, Tony Finch wrote:
> 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).

All these things are contentious which is the reason why removing it 
from the scope will hopefully aid progress.  These can be resolved in a 
follow up document.

> 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.

Except for the slow deployment issue.


> Tony.
>