From nobody Thu Sep 7 16:28:18 2023 Return-Path: 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 E48E5C14CE38; Thu, 7 Sep 2023 16:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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_ZEN_BLOCKED_OPENDNS=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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isc.org header.b="SEau3K4u"; dkim=pass (1024-bit key) header.d=isc.org header.b="bMbcSCvM" 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 laeXfoYmt97A; Thu, 7 Sep 2023 16:28:13 -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 1123EC14CEED; Thu, 7 Sep 2023 16:28:12 -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 2A7373AB006; Thu, 7 Sep 2023 23:28:12 +0000 (UTC) ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org 2A7373AB006 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=1694129292; cv=none; b=nwLp4lkjQBY7aUixiw+sXTidopDysv8+/osW6DtOvZ4x9TbbX9/S8bKWyT6/Or0d07buC+KlRL+PEv0CAlWM13TVrU3eW4M2T7YUZAh17V8KVjYNZQgbhmvSWEZSrZOWbuUpmQbKDcvS/4YAIEj3S98BKpmPpNO65MEFVGzquLI= ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1694129292; c=relaxed/relaxed; bh=PMW+Nh9a4N1woGhkrow+1ywVP0+9rLDCpZOh1YyNfVc=; h=DKIM-Signature:DKIM-Signature:Mime-Version:Subject:From:Date: Message-Id:To; b=Iz5YgA36kDVspfQCv/55weuk73F/b3qR207rlneNJ5gHk0f2qitoPJ5LT1ttMWC4KldDtSTDCSlmuvAhjxe8Ax6EvAN775nw1KFmbi8BwBI8mfV976ODwiOQRRwasWz9cLoQ5uBYxTUHbMjW0XzazAHtbluoI0hn0xXVOBe/UDE= ARC-Authentication-Results: i=1; mx.pao1.isc.org DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 2A7373AB006 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1694129292; bh=Zht4K3TknzSAs4iZuABozhJsc6l+IP/7G/vtPO65cl0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=SEau3K4u6jP5bZbKt64NViPY7pgCR7rf4N52l42WFAhyn5FQIbhYrypMc+iE0mnqY 16r9e0qPkPI+FpZZ8X3K1SsbrKb6yro2pAJYXvl0MVZuzSscgwD7A/RZr4AwbTs9TZ bB9IQl7eCUIVGlIpNoClb5y+2/40xShrQAXleRKs= Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id 240EBE6ACB3; Thu, 7 Sep 2023 23:28:12 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id F30E1E6ACB4; Thu, 7 Sep 2023 23:28:11 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org F30E1E6ACB4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1694129292; bh=PMW+Nh9a4N1woGhkrow+1ywVP0+9rLDCpZOh1YyNfVc=; h=Mime-Version:From:Date:Message-Id:To; b=bMbcSCvM1g3vmVzdaAMSFRcLtyNuP4F/HyI5Fv8xaQ1mZmujrqO8M16BoAqWhgXer WN2pmaVTZFzKc+1ZX4Nh5EdXL44knt/bfLhRKiX+ZcWJXClkNTB2MWPJuwTSb1OC/f oOq2UvNKyM8mJg8/sVWONyID275M+3Po40v9PKF8= Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavis, port 10026) with ESMTP id bGASFmdLBrvO; Thu, 7 Sep 2023 23:28:11 +0000 (UTC) Received: from smtpclient.apple (n49-187-27-239.bla1.nsw.optusnet.com.au [49.187.27.239]) by zimbrang.isc.org (Postfix) with ESMTPSA id 98EB4E6ACB3; Thu, 7 Sep 2023 23:28:10 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) From: Mark Andrews In-Reply-To: <169405896629.52551.4213112915591331764@ietfa.amsl.com> Date: Fri, 8 Sep 2023 09:27:57 +1000 Cc: The IESG , draft-ietf-dnsop-caching-resolution-failures@ietf.org, dnsop-chairs@ietf.org, dnsop WG , andrew@depht.com Content-Transfer-Encoding: quoted-printable Message-Id: <1488ACEF-1192-4407-BC98-3B36DFC0D7AA@isc.org> References: <169405896629.52551.4213112915591331764@ietfa.amsl.com> To: Paul Wouters X-Mailer: Apple Mail (2.3731.700.6) Archived-At: Subject: Re: [DNSOP] Paul Wouters' Yes on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2023 23:28:17 -0000 > On 7 Sep 2023, at 13:56, Paul Wouters via Datatracker = wrote: >=20 > Paul Wouters has entered the following ballot position for > draft-ietf-dnsop-caching-resolution-failures-07: Yes >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/about/groups/iesg/statements/handling-ballot-position= s/=20 > for more information about how to handle DISCUSS and COMMENT = positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-dnsop-caching-resolution-failu= res/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for this document and my apologies for being involved/related = to two > of the five outages you described :-) >=20 >=20 > Consistent with [RFC2308], resolution failures MUST NOT be = cached > for longer than 5 minutes. >=20 > If an expired RRSIG has a TTL of 3600, what should happen? The = resolution > failed because the signature is no longer valid but the individual > components of this validation failure are all successful lookups of = RRs that > are now in the cache. Wouldn't this result in a resolution failure of > 3600? How would an implementation limit this to 5 minutes? By deleting > the RRSIG from its cache within 5 minutes, overriding its TTL? The server shouldn=E2=80=99t be caching the RRset and it=E2=80=99s = RRSIGs unless they validate successfully. This is a requirement of DNSSEC. This is also why = recursive servers need to validate responses so that garbage is not cached. > If so, is there value stating this in the document? >=20 >=20 > also known as 'lame' >=20 > I thought the WG agreed the definition of 'lame' was not agreed upon = and > the term is no longer being favoured for use. Why not just remove this = part? >=20 > To prevent such unnecessary DNS traffic, security-aware = resolvers > MUST cache DNSSEC validation failures, with some restrictions. >=20 > What are these "some restrictions" ? >=20 >=20 >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org