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.
- [DNSOP] Do we need new draft that recommends numb… Kazunori Fujiwara
- Re: [DNSOP] Do we need new draft that recommends … Paul Vixie
- Re: [DNSOP] Do we need new draft that recommends … John Levine
- Re: [DNSOP] Do we need new draft that recommends … Mark Andrews
- Re: [DNSOP] Do we need new draft that recommends … Mark Delany
- Re: [DNSOP] Do we need new draft that recommends … John R Levine
- Re: [DNSOP] [Ext] Do we need new draft that recom… Edward Lewis