IETF Logo Mail Archive

Re: [DNSOP] Minimum viable ANAME

"John Levine" <johnl@taugh.com> Wed, 19 September 2018 20:14 UTC

Return-Path: <johnl@iecc.com>
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 3481C130E19 for <dnsop@ietfa.amsl.com>; Wed, 19 Sep 2018 13:14:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 xN_G0kSm0nDT for <dnsop@ietfa.amsl.com>; Wed, 19 Sep 2018 13:14:05 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 7CCBF128CB7 for <dnsop@ietf.org>; Wed, 19 Sep 2018 13:14:05 -0700 (PDT)
Received: (qmail 92874 invoked from network); 19 Sep 2018 20:14:01 -0000
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 19 Sep 2018 20:14:01 -0000
Received: by ary.qy (Postfix, from userid 501) id 8E0C220051382A; Wed, 19 Sep 2018 16:14:01 -0400 (EDT)
Date: Wed, 19 Sep 2018 16:14:01 -0400
Message-Id: <20180919201401.8E0C220051382A@ary.qy>
From: John Levine <johnl@taugh.com>
To: dnsop@ietf.org
Cc: dot@dotat.at
In-Reply-To: <alpine.DEB.2.20.1809191455190.3596@grey.csi.cam.ac.uk>
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/XVNZUfPzNb993BGpEeWLX3wdGVs>
Subject: Re: [DNSOP] Minimum viable ANAME
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: Wed, 19 Sep 2018 20:14:07 -0000

In article <alpine.DEB.2.20.1809191455190.3596@grey.csi.cam.ac.uk> you write:
>Authoritative servers / zone transfers
>--------------------------------------
>
>No special new behaviour.
>
>
>Additional section processing
>-----------------------------
>
>This applies to auth and rec servers. In response to an A / AAAA /
>ANAME query, include any sibling A / AAAA / ANAME records, and any
>ANAME target A / AAAA records. When DO=1, include DNSSEC proofs of
>nonexistence for missing RRsets.

If I look up foo and it has an ANAME to bar, which of these do I get
back?

foo. ANAME bar.
foo. A 1.2.3.4


foo. ANAME bar.
bar. A 1.2.3.4


The second is a lot more like what CNAME does, and also avoids having
to sign on the fly.  There is of course the question of whether caches
and stubs will treat them like cname results or like cache poisoning.

R's,
John

PS: I still think fixing apex CNAME is a better way to go.

v2.23.0 | Report a Bug | By Email