Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

Evan Hunt <each@isc.org> Sun, 24 June 2018 04:36 UTC

Return-Path: <each@isc.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 77DBB12F1A2 for <dnsop@ietfa.amsl.com>; Sat, 23 Jun 2018 21:36:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 sA85C2tQD1wd for <dnsop@ietfa.amsl.com>; Sat, 23 Jun 2018 21:36:52 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 CA525124D68 for <dnsop@ietf.org>; Sat, 23 Jun 2018 21:36:52 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id B56A13AB03F; Sun, 24 Jun 2018 04:36:50 +0000 (UTC)
Received: by bikeshed.isc.org (Postfix, from userid 10292) id 9A4EF216C1C; Sun, 24 Jun 2018 04:36:50 +0000 (UTC)
Date: Sun, 24 Jun 2018 04:36:50 +0000
From: Evan Hunt <each@isc.org>
To: Joe Abley <jabley@hopcount.ca>
Cc: dnsop@ietf.org
Message-ID: <20180624043650.GA95868@isc.org>
References: <b73f3dc7-b378-d5d8-c7a2-42bc4326fbae@nic.cz> <alpine.DEB.2.11.1806191428250.916@grey.csi.cam.ac.uk> <CAJhMdTO2kj+nUqESg3ew=wwZuB9OzkJE6pST=mae7pHiEk4-Qw@mail.gmail.com> <20180623210416.GA12346@mournblade.imrryr.org> <CAJhMdTNzOUSjTmnorzrJze9F7Gcc+eWAjqii_4uJ4UmJPvQC-Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAJhMdTNzOUSjTmnorzrJze9F7Gcc+eWAjqii_4uJ4UmJPvQC-Q@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/KTP0q9Jora7MDaPQJibISkyJI_Y>
Subject: Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.26
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: Sun, 24 Jun 2018 04:36:56 -0000

On Sat, Jun 23, 2018 at 07:43:19PM -0700, Joe Abley wrote:
> I think a pragmatic solution needs to work in unsigned zones.

+1, but, an unsigned zone could still return an NSEC-style bitmap.  It
wouldn't be provably correct, but neither is any other unsigned response.

You could actually add the bitmap to the XNAME rdata, instead of returning
an NSEC. The XNAME could then mean "alias to <name> for any rrtype not in
<bitmap>". Or you could turn it around, and have it mean "alias to <name>
for any rrtype that IS in <bitmap>". Then you could have multiple XNAME
records with different bitmaps, and forward different types to different
names.  That's kind of cool, but I suspect the benefits are outweighed by
the camel burden.

In any case, I don't understand how XNAME avoids the "ANAME kludges".
Legacy resolvers won't know what to do with XNAME, so all the same
workarounds on the auth side still must be implemented.  Possibly even more
of them, since XNAME responses might need to include answers for lots
of different rrtypes, while ANAME is explicitly limited to A and AAAA.

-- 
Evan Hunt -- each@isc.org
Internet Systems Consortium, Inc.