[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, 6 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.