Re: [DNSOP] Fundamental ANAME problems

Paul Vixie <paul@redbarn.org> Fri, 02 November 2018 08:21 UTC

Return-Path: <paul@redbarn.org>
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 583BB12008A for <dnsop@ietfa.amsl.com>; Fri, 2 Nov 2018 01:21:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 Ksw0mbAY4y8d for <dnsop@ietfa.amsl.com>; Fri, 2 Nov 2018 01:21:44 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23EBA12F1A6 for <dnsop@ietf.org>; Fri, 2 Nov 2018 01:21:44 -0700 (PDT)
Received: from linux-9daj.localnet (dhcp-161.access.lah1.vix.su [24.104.150.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id CD29B892C6; Fri, 2 Nov 2018 08:21:43 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: dnsop@ietf.org
Date: Fri, 02 Nov 2018 08:21:01 +0000
Message-ID: <10630817.EBhDirc4SB@linux-9daj>
Organization: Vixie Freehold
In-Reply-To: <alpine.OSX.2.21.1811021557350.13429@ary.local>
References: <CAH1iCirXYsYB3sAo8f1Jy-q4meLmQAPSFO-7x5idDufdT_unXQ@mail.gmail.com> <CAH1iCioGbweYndujWRsHFJ5ZJz+NXkL-_cyB13Xq4m5Espbmpw@mail.gmail.com> <alpine.OSX.2.21.1811021557350.13429@ary.local>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/fQ8OgWm521sdeZ6YgShB_qhKPZ0>
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, 02 Nov 2018 08:21:47 -0000

i think an ANAME whose only purpose was to inform some outer process that AAAA 
and A RRsets should be copied from somewhere periodically using RFC 2136 
UPDATE messages, could be useful if some name server implementors decided to 
offer the feature of doing this internally, "as if UPDATE had been done" but 
not actually requiring a cron job and perl script and so on. it would likely 
be seen as a reasonable compromise by the CNAME flattening DNS hosters of the 
era, and may lead to interoperability.

for better dynamicism we should be pushing SRV. and there's no reason why an 
FYI document couldn't explain how to use an apex SRV to inform an UPDATE of 
apex AAAA and A RRsets. this, too, could be added as a nonstandard enhancement 
to authority servers who could do it internally, without cron or perl.

it's very likely that the high volume sites of the world will just go on using 
CDN as before, where every apex AAAA or A query is crafted by load estimating 
or triangulation software, no matter what we do here. however, something like 
ANAME, or something like ANAME but based on apex SRV, could be used to inform 
that estimation/triangulation, and could lead to greater interoperability. i'm 
not sure CDN's currently want interoperability, due to competition concerns, 
but i expect that their customers would like a multi-CDN option to avoid lock-
in.

in other words i don't think there's a glaring need for elegance on this one.

vixie