Re: [DNSOP] CNAME chain length limits

John R Levine <johnl@taugh.com> Thu, 28 May 2020 03:24 UTC

Return-Path: <johnl@taugh.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 618293A0B68 for <dnsop@ietfa.amsl.com>; Wed, 27 May 2020 20:24:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=At/jGa7Q; dkim=pass (1536-bit key) header.d=taugh.com header.b=wUKCf5+M
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 U_uALKAU5uYr for <dnsop@ietfa.amsl.com>; Wed, 27 May 2020 20:24:35 -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 6D7A53A0B67 for <dnsop@ietf.org>; Wed, 27 May 2020 20:24:34 -0700 (PDT)
Received: (qmail 3356 invoked from network); 28 May 2020 03:24:33 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=d19.5ecf2ef1.k2005; i=johnl-iecc.com@submit.iecc.com; bh=BPh6fmLtzxze5wH2G+daZVv6adR3FYyzK0cEmZdFzG0=; b=At/jGa7QvxI9LnPagwvMy2lJWtCSfCT8YIBS5NZTsvFPgL7J9Vj5boYHa7WZqaZyxgaBFXJHa8YQMlURWTUQ/2O9URRXao2rrocHIPqnKdVf8iYQkQrmLQAOEJROR8VlG25UJwMKfVkdTNCVdaugTXVsQ0Z96aGtpOAKzyVlwOQJ2tvCJLxUhv6XwBlkhgzPoKkprTvVvMv1//LqlT1HcB5wxjocbBYkxoTivt24m2lGCc0D2Msy+CX9V28M+OD0
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=d19.5ecf2ef1.k2005; olt=johnl-iecc.com@submit.iecc.com; bh=BPh6fmLtzxze5wH2G+daZVv6adR3FYyzK0cEmZdFzG0=; b=wUKCf5+MaA7kIsKyHlgNhE+LrqS9pA0ciCN3MwpDMsbKogAg0k4urCi9nT94onxQL86SBOKNKBsa2b07FDcXzbCRCZSfBDJ0DlKEWn8Ou2X5xUKuAes+JUYzWQ3ACxWgL16oVdFC+LBrQ9olgdyDxdo19klV1ypNYiREmDsvqC6OIAJKwyZTGxXYcF6i31FuL8FPBKSmp8RQ0vXlFGPW6VaJzu/C/HQky/gv4WZeOqHOvWgvcIyzCI9HP/IpnAGV
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 28 May 2020 03:24:32 -0000
Date: Wed, 27 May 2020 23:24:32 -0400
Message-ID: <alpine.OSX.2.22.407.2005272317320.39824@ary.qy>
From: John R Levine <johnl@taugh.com>
To: dagon <dagon@sudo.sh>
Cc: dnsop@ietf.org
In-Reply-To: <20200528024410.GA7675@sudo.sh>
References: <alpine.OSX.2.22.407.2005271341530.35268@ary.qy> <20200527180846.GA51895@isc.org> <20200527200614.GC3582@sudo.sh> <alpine.DEB.2.20.2005280101240.18104@grey.csi.cam.ac.uk> <20200528024410.GA7675@sudo.sh>
User-Agent: Alpine 2.22 (OSX 407 2020-02-09)
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/5w5dV0WpZmX6PaaQytKat5KMKEw>
Subject: Re: [DNSOP] CNAME chain length limits
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: Thu, 28 May 2020 03:24:37 -0000

On Thu, 28 May 2020, dagon wrote:
> On Thu, May 28, 2020 at 01:02:47AM +0100, Tony Finch wrote:
>> dagon <dagon@sudo.sh> wrote:
>>>
>>>   -- Tests for ("improper") horizontal vs. vertical CNAMEs.  Some
>>>      recursive speakers fail; some complain ("BAD (HORIZONTAL)
>>>      REFERRAL", but answer), and some follow without complaint.
>>
>> Can you explain what these are, please?
>
> If a canonical answer points to the same level as the 'owner name',
> then the left and right sides share NS.  (This is the most common
> case, and even outlined in 1034.)  If this discovery occurs during a
> CNAME chain chase with yet another empty answer, the NS is in a sense
> making a referral to itself, or its pool of secondary NS serving the
> same delegation cut level---the bad horizontal referral.

It sounds like "horizontal" means within the same zone, and "vertical" 
means a different zone.  I don't know what you mean by "level" -- same 
number of components in the name? All but the last component the same? 
In the same zone?  Something else?

In RFC 1034 CNAMEs are intended as short term transition aidss, sort of 
like yellow forwarding stickers on paper mail.  Now they're mostly used to 
dynamically delegate names across authority boundaries, which works pretty 
well, but there's a lot of ancient cruft still sticking to them.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly