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

Joe Abley <jabley@hopcount.ca> Tue, 19 June 2018 14:59 UTC

Return-Path: <jabley@hopcount.ca>
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 49253130EA8 for <dnsop@ietfa.amsl.com>; Tue, 19 Jun 2018 07:59:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 20ynKybgAwKM for <dnsop@ietfa.amsl.com>; Tue, 19 Jun 2018 07:59:38 -0700 (PDT)
Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C70130E9F for <dnsop@ietf.org>; Tue, 19 Jun 2018 07:59:37 -0700 (PDT)
Received: by mail-lf0-x230.google.com with SMTP id p23-v6so18939745lfh.11 for <dnsop@ietf.org>; Tue, 19 Jun 2018 07:59:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc:content-transfer-encoding; bh=3oNDZqWlSPKbIpgaErjbl1bx+utWwchaYLoBVna8HUw=; b=psWapfdC8Om+wrtKrl+xMh9ZvftngXfWLjHv2OCr+j5ce8f6TThWYBNojUBUAC1kTb PjlHJyIpSGOeXEFljp+n00r6gWz139wYSM8y6icl6RMx0zxpXdWfeakkhAzaYXwTm8bh FHzb/EfB2S3KgwiSvRtO8R38HjvYAgferR5yE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc:content-transfer-encoding; bh=3oNDZqWlSPKbIpgaErjbl1bx+utWwchaYLoBVna8HUw=; b=YV9BfKRTewK48NNbrnoYInzPt2Z988OLp9PcFlTgCURdP7zqnKbv1xdmMw6K7Mf0wZ CPl3fRY0dNU4dhHG9ihbupKKpYcbxuzCpjQbWho0YivGJC136XZkdNH4CZFkY0W0W4Cl hEWAXd4uFImFZuiNMEjTnSy/e7R9vZvXiC2RevrMNQqMa3Lw5uRBk+CrKIgfh+LY9M06 5EqFhUDWnUBWRhE1Nm8Vp0JZ8/CfjG9yUNzR93ya1RgZkowsHzoV1XODlrWljXVxO1G4 wD6Pphm+CTnerFedobHSD2jG/frsGg9W2sgalYQ/iJgdTY/Rv067PYfrh7NfmvK+6Gal cEoA==
X-Gm-Message-State: APt69E0DE19tR5Td4XeQui+ZRmXs8uuwmDCzj4yJrLf5O8DIetVNi6eU OU2VsLFOgpbwsZHb6rXzhbRbDqOnFFN7EflbgmwKoA==
X-Google-Smtp-Source: ADUXVKLwFNnJUyFset/KYdWh8Mu5JmtlQRY6NHjdhHjv+NhoEOVqT2T2ycyduI9GyZM8UInK5BF3sHAYmMgCBxtrHNk=
X-Received: by 2002:a19:be52:: with SMTP id o79-v6mr4637957lff.108.1529420375962; Tue, 19 Jun 2018 07:59:35 -0700 (PDT)
Received: from unknown named unknown by gmailapi.google.com with HTTPREST; Tue, 19 Jun 2018 07:59:34 -0700
From: Joe Abley <jabley@hopcount.ca>
Mime-Version: 1.0 (1.0)
References: <b73f3dc7-b378-d5d8-c7a2-42bc4326fbae@nic.cz> <alpine.DEB.2.11.1806191428250.916@grey.csi.cam.ac.uk>
In-Reply-To: <alpine.DEB.2.11.1806191428250.916@grey.csi.cam.ac.uk>
Date: Tue, 19 Jun 2018 07:59:34 -0700
Message-ID: <CAJhMdTO2kj+nUqESg3ew=wwZuB9OzkJE6pST=mae7pHiEk4-Qw@mail.gmail.com>
To: Tony Finch <dot@dotat.at>
Cc: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <petr.spacek@nic.cz>, "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2nArMz-4UlekgThb-xu-doxhtsQ>
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:59:41 -0000

On Jun 19, 2018, at 10:20, Tony Finch <dot@dotat.at>; wrote:

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

My memory of the specifics about the various ANAME/BNAME/ALIAS/etc
proposals or non-standard features is fuzzy so the following may miss
the point (apologies if so, as usual).

However, it sounds a bit like what is being proposed in this thread
(generally, not in your specific message) is for CNAME to be treated
on authority servers like a wildcard RRTYPE for a particular owner
name. The response behaviour if a CNAME is present at the owner name
matching the QTYPE but there is no corresponding RRTYPE in the zone is
to return a NOERROR/CNAME response instead of a NODATA response.

For recursive servers the change that is required is to keep track of
what QTYPEs triggered particular CNAMEs in the cache so that new-QTYPE
cache misses trigger an upstream query.

All of this needs to be extended along the edns-client-subnet axis.

All of the corner cases relating to existing CNAME behaviour, both
standardised and not, on recursive servers, stub resolvers and
authority servers needs to be specified.

This sounds like a lot of work and likely to cause camel indigestion.

However assuming the initial thesis was correct and there is demand
for this functionality (seems right to me) using a new RRTYPE for this
still sounds easier than changing the semantics of CNAME.

Perhaps the new RRTYPE could include an encoding of explicit types
that do exist to make life easier for resolvers.

Perhaps we could call the RRTYPE "*" instead of ENAME or FNAME to
avoid encouraging future GNAME and HNAME proposals :-)


Joe