IETF Logo Mail Archive

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

Mark Andrews <marka@isc.org> Tue, 12 March 2024 21:39 UTC

Return-Path: <marka@isc.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 8D805C14F6AC for <dnsop@ietfa.amsl.com>; Tue, 12 Mar 2024 14:39:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.108 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isc.org header.b="qMu7eba3"; dkim=pass (1024-bit key) header.d=isc.org header.b="cEWeCYSN"
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 8AdLGnpFEiu0 for <dnsop@ietfa.amsl.com>; Tue, 12 Mar 2024 14:39:23 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.2.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E0A8C14F690 for <dnsop@ietf.org>; Tue, 12 Mar 2024 14:39:22 -0700 (PDT)
Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.2.31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 484C53AB016; Tue, 12 Mar 2024 21:39:21 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org 484C53AB016
Authentication-Results: mx.pao1.isc.org; arc=none smtp.remote-ip=149.20.2.31
ARC-Seal: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1710279561; cv=none; b=Wib89K9rKkPWcc1XOk8GTH8fNU5ptEGfcQsWvvhzMnghF1uVEizhnlAYHV7hZKml8CqvAi+RkUsdmgwBAjLLBXTWaiIR6gM8qpiR17ADPAF7WxeUbJv0g2ZtmaYcGWM+GT0EuqgqxqCQ4d0ujRIglituZU2qKKozpKnSVINl40s=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1710279561; c=relaxed/relaxed; bh=UzLUEL8XJ0w60x1RPs4vgAuYaCECJ0tS+GJsYBX4q78=; h=DKIM-Signature:DKIM-Signature:Mime-Version:Subject:From:Date: Message-Id:To; b=C/MNzaUqybmNIvDJOvKp18/KXwbjX8DmLrQUxRJF6PscBPB3lhVf3si9fPHgU4YPecTv/nOHUxtF1yYKhStxowEZleC6qPcLCDbvn0YnbzWgsQ+ydn2+st+9sOlZg+0na3vsKD1BQoZHQfnaU8RysnEgNoPWrHPMKgts37G4P7w=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 484C53AB016
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1710279561; bh=7gqrz4tsC3u9iy0cNWjw5Hae4WE9Wja2ktxu9sRwpVU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=qMu7eba3rdhQxKX/+j4lNDFm8xKzMYIsGj3inX0i3WuIne3DsZWNk0+Nc6MmbSyos ZqlFP0YtXB17geZxDcZPSygAYFYOAaqMPXuy+wHr78Z6ba/xmO/uYC3QarlyUNiFkp cHhYN8Mf8TZwv1+MOLpZVal2Hn2blOAafiNWLG20=
Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id 42D03DEA7DB; Tue, 12 Mar 2024 21:39:21 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id 20C86DEA83E; Tue, 12 Mar 2024 21:39:21 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org 20C86DEA83E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1710279561; bh=UzLUEL8XJ0w60x1RPs4vgAuYaCECJ0tS+GJsYBX4q78=; h=Mime-Version:From:Date:Message-Id:To; b=cEWeCYSNLnf0Dj5UxAeb6Q/rj/TCpbDVjYlJv3YV/N8jZkNngvBEv0PeHkmtSGW4w qBltHbF0OgjmiN3V/sy264P4aaMs39LkthPtjgYjiNSDwtLq/I92rHxg/fIj+OL6aH MVLV5fE1b0h9ptOLLPR8/mXEazODe8bWlja0yhN0=
Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavis, port 10026) with ESMTP id YN6oiD9Yf1_D; Tue, 12 Mar 2024 21:39:21 +0000 (UTC)
Received: from smtpclient.apple (n49-187-18-238.bla1.nsw.optusnet.com.au [49.187.18.238]) by zimbrang.isc.org (Postfix) with ESMTPSA id 57B07DEA7DB; Tue, 12 Mar 2024 21:39:20 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <20240312164614.36BF88504657@ary.qy>
Date: Wed, 13 Mar 2024 08:39:08 +1100
Cc: dnsop@ietf.org, paul@redbarn.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0247583E-EB0C-4703-B07C-E85E46649F4A@isc.org>
References: <20240312164614.36BF88504657@ary.qy>
To: John Levine <johnl@taugh.com>
X-Mailer: Apple Mail (2.3731.700.6.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/DAqv9H6YFlOvH5M1q9axxzHOkes>
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 21:39:27 -0000


> On 13 Mar 2024, at 03:46, John Levine <johnl@taugh.com> wrote:
> 
> It appears that Paul Vixie  <paul@redbarn.org> said:
>> -=-=-=-=-=-
>> <<Rather than writing a draft for each limitation,
>> 
>> I think it would be better to compile them all into one draft.>>
> 
> I agree a draft describing the places where DNS evaluators
> should set limits would be a good idea.
> 
> I am considerably less enthusastic about specific limits, since
> the use of the DNS has evolved a lot and some things that may
> bave seemed excessive back in the day are now routine.
> 
> The obvious example is CNAME chains. In 1034/1035 the only use
> contemplated for CNAME was temporary forwarding when a host name
> changed, and for that use, chained CNAMEs made no sense. Now they
> delegate authority to different points of control in many different
> 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.
That in turn results in amplification bug reports being reported from
universities looking for the latest way to abuse the DNS to launch
DoS attacks.  And it is not 3 CNAMEs, you are looking at 5+ CNAMEs
today.

From a recent pcap 

CNAME XXXXXXXX.Clump.YYYYYYYY.aa-rt.sharepoint.com., CNAME ZZZZZZZZZ.Farm.KKKKKKKK.aa-rt.sharepoint.com., CNAME LLLLLLLLL.Farm.BBBBBBBBBB.sharepointonline.com.akadns.net., CNAME AAAAAAA.farm.RRRRRRR.aa-rt.sharepoint.com.dual-spo-0005.spo-msedge.net., CNAME YYYYYYYY.spo-msedge.net

If you reduce the number of supported CNAMES you get “but it works with
Google” thrown back at you when in reality there isn’t a need for most
of this.  All of the CNAMES could be done in the background rather than
polluting caches with chains of CNAMES.

> R's,
> John
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org

v2.23.0 | Report a Bug | By Email