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

Viktor Dukhovni <ietf-dane@dukhovni.org> Sun, 24 June 2018 19:42 UTC

Return-Path: <ietf-dane@dukhovni.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 86243130E50 for <dnsop@ietfa.amsl.com>; Sun, 24 Jun 2018 12:42:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.715
X-Spam-Level:
X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, RCVD_IN_DNSWL_MED=-2.3, 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 VLTwgLg1ZP66 for <dnsop@ietfa.amsl.com>; Sun, 24 Jun 2018 12:42:37 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CC98130E33 for <dnsop@ietf.org>; Sun, 24 Jun 2018 12:42:37 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5CEE87A330A; Sun, 24 Jun 2018 19:42:36 +0000 (UTC)
Date: Sun, 24 Jun 2018 19:42:36 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop@ietf.org
Message-ID: <20180624194236.GC12346@mournblade.imrryr.org>
Reply-To: dnsop@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20180624043650.GA95868@isc.org> <CAJhMdTNzOUSjTmnorzrJze9F7Gcc+eWAjqii_4uJ4UmJPvQC-Q@mail.gmail.com>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/0xJ30X30VhQh0IfngedVQyHYo24>
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 19:42:41 -0000

On Sat, Jun 23, 2018 at 07:43:19PM -0700, Joe Abley wrote:

> > Yes, but if they have the NSEC bitmap, they can follow the XNAME
> > without asking again.
> > [...]
> > That's already handled by NSEC/NSEC3.
> 
> I think a pragmatic solution needs to work in unsigned zones.

For unsigned zones a synthetic NSEC record can (and should) be
returned unsigned,

	example.com. IN "XNAME" www.example.net.
	example.com. IN NSEC \0.example.com. SOA NS MX "XNAME"

> If an XNAME proposal was to solve real-world problems for these people
> it would need to work with or without DNSSEC.
> [...]
> (And I wasn't entirely serious about calling the wildcard RRTYPE * :-)

Good, but actually, for "XNAME" to solve real-world problems, what's
needed is XNAME == CNAME.  Anything else faces deployment hurdles,
as applications have to be updated to support the new record.
CNAMEs are already understood, so just generalize them to be a
fallback redirect for RRtypes not explicitly configured.

On Sun, Jun 24, 2018 at 04:36:50AM +0000, Evan Hunt 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.

Agreed.

> You could actually add the bitmap to the XNAME rdata, instead of returning
> an NSEC.

But that requires a new "XNAME" rrtype, whereas what the users want
is a more flexible CNAME that coëxists with other RRtypes.  And
so in the unsigned case, an NSEC RR can ride along to provide the
information that the CNAME is of the new kind that lives alongside
some other records.

> The XNAME could then mean "alias to <name> for any rrtype not in
> <bitmap>".

I think that's the more appropriate definition.  Anything else
would require considerable new machinery.

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

By making: XNAME == CNAME.

-- 
	Viktor.