Re: [DNSOP] SVCB chain lengths

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Tue, 24 December 2019 02:00 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
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 7A372120D25 for <dnsop@ietfa.amsl.com>; Mon, 23 Dec 2019 18:00:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 rGw5DaLpvEBJ for <dnsop@ietfa.amsl.com>; Mon, 23 Dec 2019 18:00:55 -0800 (PST)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id A374E120D22 for <dnsop@ietf.org>; Mon, 23 Dec 2019 18:00:54 -0800 (PST)
Received: (qmail 70726 invoked from network); 24 Dec 2019 01:46:29 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 24 Dec 2019 01:46:29 -0000
To: dnsop@ietf.org
References: <CAMOjQcGP3=+_fb9pt3dvF27kR1ENH+=2L28EDNPQU6JF8zkrzQ@mail.gmail.com> <CAH1iCirdFrT_v-FBqaC=WUfaY52DyeYLh5VWbeVsw2YwscDCpA@mail.gmail.com> <CAHbrMsBAmQU-xduT3E4_sHaqrpsdZ_YfdEtgoNB4kti4jDCvdQ@mail.gmail.com> <CAH1iCip0iY8Mt8=HC0-V8jF=D=BGcs54xUMu4Rkbe47FFxGyuA@mail.gmail.com> <CAMOjQcG2YOBa1X7ZqAUpDG0Cwr+nOzmy-bKJmbqaQEqrcTOCAQ@mail.gmail.com>
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-ID: <0b789851-b0b3-3d5e-1983-6d03675b96f1@necom830.hpcl.titech.ac.jp>
Date: Tue, 24 Dec 2019 11:00:49 +0900
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <CAMOjQcG2YOBa1X7ZqAUpDG0Cwr+nOzmy-bKJmbqaQEqrcTOCAQ@mail.gmail.com>
Content-Type: text/plain; charset="iso-2022-jp"; format="flowed"; delsp="yes"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/z38ADEg9lMbUT0zV14GPDAITb1M>
Subject: Re: [DNSOP] SVCB chain lengths
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: Tue, 24 Dec 2019 02:00:57 -0000

Eric Orth wrote:

> CNAMEs already exist without a standardized limit.  Good or bad, too late
> to change that without breaking things.

According to rfc1034:

	Domain names in RRs which point at another name should
	always point at the primary name and not the alias.

CNAME chain is prohibited, though, according to the robustness
principle, the rfc says chains should be followed.

 > aliasing apex names, are new and thus currently limited to zero.

Seems to be a reasonable restriction.

						Masataka Ohta