IETF Logo Mail Archive

Re: [DNSOP] SVCB chain lengths

Paul Vixie <paul@redbarn.org> Mon, 23 December 2019 21:09 UTC

Return-Path: <paul@redbarn.org>
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 BDD15120043 for <dnsop@ietfa.amsl.com>; Mon, 23 Dec 2019 13:09:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 Y9hUH46rp8B8 for <dnsop@ietfa.amsl.com>; Mon, 23 Dec 2019 13:09:03 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B363612099B for <dnsop@ietf.org>; Mon, 23 Dec 2019 13:09:03 -0800 (PST)
Received: from linux-9daj.localnet (50-255-33-26-static.hfc.comcastbusiness.net [50.255.33.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id DB708B0591; Mon, 23 Dec 2019 21:09:00 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: dnsop <dnsop@ietf.org>
Cc: Eric Orth <ericorth=40google.com@dmarc.ietf.org>
Date: Mon, 23 Dec 2019 21:08:59 +0000
Message-ID: <63087299.94DxYQgZpW@linux-9daj>
Organization: none
In-Reply-To: <CAMOjQcG2YOBa1X7ZqAUpDG0Cwr+nOzmy-bKJmbqaQEqrcTOCAQ@mail.gmail.com>
References: <CAMOjQcGP3=+_fb9pt3dvF27kR1ENH+=2L28EDNPQU6JF8zkrzQ@mail.gmail.com> <CAH1iCip0iY8Mt8=HC0-V8jF=D=BGcs54xUMu4Rkbe47FFxGyuA@mail.gmail.com> <CAMOjQcG2YOBa1X7ZqAUpDG0Cwr+nOzmy-bKJmbqaQEqrcTOCAQ@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/3NdL-UrN5yERdzSXtTA4ss7_bxE>
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: Mon, 23 Dec 2019 21:09:06 -0000

On Monday, 23 December 2019 20:22:01 UTC Eric Orth wrote:
> Maybe it would help if we scoped down any chain limiting:
> 
> 1) Any chain limiting only applies to SVCB alias form, not CNAME.
> 
> CNAMEs already exist without a standardized limit.  Good or bad, too late
> to change that without breaking things.  ...

CNAME loops must be detected, so whatever unstandardized limit is chosen, must 
be both greater than one, and finite. i agree with your associated SVCB 
reasoning, but we should be clear here that there are standardized boundaries 
for CNAME chain lengths, even if there is no specific standardized limit for 
same.

-- 
Paul

v2.23.0 | Report a Bug | By Email