Re: [DNSOP] Do we need new draft that recommends number limits ?

Mark Delany <m9p@india.emu.st> Tue, 12 March 2024 22:18 UTC

Return-Path: <m9p@india.emu.st>
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 EBCB9C14F6B3 for <dnsop@ietfa.amsl.com>; Tue, 12 Mar 2024 15:18:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.985
X-Spam-Level:
X-Spam-Status: No, score=-0.985 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, MISSING_HEADERS=1.021, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emu.st
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-aqujFzAXzG for <dnsop@ietfa.amsl.com>; Tue, 12 Mar 2024 15:18:36 -0700 (PDT)
Received: from f3.bushwire.net (f3.emu.st [IPv6:2403:580c:e522:0:203:0:120:11]) by ietfa.amsl.com (Postfix) with ESMTP id A7B46C14F6B1 for <dnsop@ietf.org>; Tue, 12 Mar 2024 15:18:35 -0700 (PDT)
Received: by f3.bushwire.net (Postfix, from userid 1001) id 2EF2B4E627; Wed, 13 Mar 2024 08:18:32 +1000 (AEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1710281912; bh=+wlfUHLgWF2CcX7selIySj1ehME=; h=Comments:Received:From:Comments:Message-ID:Date:Cc:Content-Type: Subject:References:Mime-Version:Content-Disposition:In-Reply-To; b=RXeyfz1PSI6MuWYbTqDsCTva7alE8BiDmaSKrF5BDTgNHTJTg96ygwB+oBcl4Er3i QbTnpGraxFNWx8gboAdQ8hyG8URBEOWF6DSE1Fxr2LdvtvoiQ2gT2dVCrOybUiMR54 0arjohqu2Xbv3/ZaxEQmSXiw2o35JOHEpbDUr7zg=Ur7zg=
Comments: QMDA 0.3a
Received: (qmail 34511 invoked by uid 1001); 12 Mar 2024 22:18:32 -0000
From: Mark Delany <m9p@india.emu.st>
Comments: QMDASubmit submit() 0.2.0-final
Message-ID: <0.2.0-final-1710281912.142-0xcb168b@qmda.emu.st>
Date: Tue, 12 Mar 2024 22:18:32 +0000
Cc: dnsop@ietf.org
Content-Type: text/plain; charset="utf-8"
References: <20240312164614.36BF88504657@ary.qy> <0247583E-EB0C-4703-B07C-E85E46649F4A@isc.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <0247583E-EB0C-4703-B07C-E85E46649F4A@isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/vllge7LH1IjSJa1IlWap2p1U1tw>
Subject: Re: [DNSOP] Do we need new draft that recommends number limits ?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
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, 12 Mar 2024 22:18:42 -0000

On 13Mar24, Mark Andrews apparently wrote:
> > ways. For applications like CDNs, you need two or three link CNAME
> > chains and nobody appears to find that a problem.
> 
> Actually it is a problem.  It results in lots of additional lookups.

> of this.  All of the CNAMES could be done in the background rather than
> polluting caches with chains of CNAMES.

Absolutely. It's always struck me as a copout that some CDN providers externalize their
infrastructure costs onto every DNS cache on the planet.

Is there any fundamental reason why a CDN provider can't make their external facing DNS do
all that CNAME resolution internally and just forward the final answer? Not only would
that likely speed up client resolution time, it'll also reduce the amount of thrashing in
DNS caches around the world.

But sadly, that ship has well and truly left port, and now we're deciding whether any
reasonably limit can be set and how it would be enforced.

And "enforcement" is probably the biggest benefit of a central document which spells out
limits, that cache implementors at least have somewhere to point when a limit is
exceeded. But that would imply that said document has more "MUSTs" than "SHOULDs" or
"RECOMMENDEDs" in it. Is that what people are prepared to do? Otherwise a document which
merely suggests a limit is likely to be of, ahem, limited value.


Mark.