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

Tony Finch <dot@dotat.at> Tue, 19 June 2018 14:20 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 1D5D5130EFA for <dnsop@ietfa.amsl.com>; Tue, 19 Jun 2018 07:20:54 -0700 (PDT)
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 KsWBDMSE_imu for <dnsop@ietfa.amsl.com>; Tue, 19 Jun 2018 07:20:51 -0700 (PDT)
Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 B0FA1130F3B for <dnsop@ietf.org>; Tue, 19 Jun 2018 07:20:51 -0700 (PDT)
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]:40455) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fVHV3-000Y3c-02 (Exim 4.91) (return-path <dot@dotat.at>); Tue, 19 Jun 2018 15:20:49 +0100
Date: Tue, 19 Jun 2018 15:20:48 +0100
From: Tony Finch <dot@dotat.at>
To: Petr Špaček <petr.spacek@nic.cz>
cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
In-Reply-To: <b73f3dc7-b378-d5d8-c7a2-42bc4326fbae@nic.cz>
Message-ID: <alpine.DEB.2.11.1806191428250.916@grey.csi.cam.ac.uk>
References: <b73f3dc7-b378-d5d8-c7a2-42bc4326fbae@nic.cz>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="1870870841-1202050623-1529418049=:916"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/EJZ9WPtVYxZd5hrwWF2ip2Cst9o>
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: Tue, 19 Jun 2018 14:20:55 -0000

Petr Špaček <petr.spacek@nic.cz> wrote:
>
> Given that resolver side somehow works already ...
> could we standardize this obvious violation of RFC 1035?

The feature I would like is CNAME and other data (typically CNAME + MX +
TXT), because I have a lot of deeply hierarchial subdomains in my main
zone. CNAME at apex does not need to be (and I think should not be treated
as) a special case.

As I understand it, in the RFC 883 era, CNAME was allowed to coexist with
other records, but that led to consistency problems. eg, if you have a
CNAME cached for a particular name, and you get a query for MX at the same
name, do you go and ask the CNAME's owner or its target for the MX? And do
you get a different answer to the MX query when you don't have a CNAME
cached?

My guess is that it was hard to fix this at the time because the semantics
of negative cache entries was not well developed (e.g. RFC 1034 section
4.3.4 says it was still a new and experimental feature). For
CNAME-with-siblings to work, a resolver needs to remember whether it
already asked for the other data, for each RR type. 1980s caches couldn't
do this, so CNAMEs were made exclusive instead.

I think the resolver's algorithm for handling CNAMEs can be updated to
allow CNAME-with-siblings and preserve compatibility. There will be some
latency cost for later queries that can no longer immediately follow the
CNAME shortcut. NSEC/NSEC3 records could be used to eliminate this cost.

I'm much less sure about whether it's possible to publish
CNAME-with-siblings in a reliably compatible way. I would feel a lot more
comfortable with an ANAME implementation that copies the sibling records
from the target to the owner when the zone is published or signed.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Trafalgar: Cyclonic, mainly northeasterly in northwest, 5 to 7. Slight or
moderate until later in southeast, otherwise moderate or rough. Thundery
showers, fog patches later. Moderate or good, occasionally very poor later.