IETF Logo Mail Archive

Re: [DNSOP] I-D Action: draft-ietf-dnsop-compact-denial-of-existence-03.txt

Dave Lawrence <tale@dd.org> Sun, 17 March 2024 23:32 UTC

Return-Path: <tale@dd.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 40EA9C14F682 for <dnsop@ietfa.amsl.com>; Sun, 17 Mar 2024 16:32:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 nCUOZXkI96Na for <dnsop@ietfa.amsl.com>; Sun, 17 Mar 2024 16:32:28 -0700 (PDT)
Received: from fluff.twonth.com (fluff.twonth.com [45.79.143.238]) (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 CD0E9C14F680 for <dnsop@ietf.org>; Sun, 17 Mar 2024 16:32:28 -0700 (PDT)
Received: from gro.dd.org (c-76-23-204-191.hsd1.vt.comcast.net [76.23.204.191]) by fluff.twonth.com (Postfix) with ESMTPS id 2C4AF1FE72 for <dnsop@ietf.org>; Sun, 17 Mar 2024 23:32:28 +0000 (UTC)
Received: by gro.dd.org (Postfix, from userid 102) id CFB5E1887ED; Sun, 17 Mar 2024 19:32:27 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-ID: <26103.32139.822825.290467@gro.dd.org>
Date: Sun, 17 Mar 2024 19:32:27 -0400
From: Dave Lawrence <tale@dd.org>
To: dnsop@ietf.org
In-Reply-To: <CAHPuVdXgS00nJqpvr-dfWAKoUiA=vvSORBtNrGG5kyBSxrkByQ@mail.gmail.com>
References: <26102.24462.696376.343194@gro.dd.org> <20240317160745.A4ED8858A5F3@ary.qy> <CAHPuVdXgS00nJqpvr-dfWAKoUiA=vvSORBtNrGG5kyBSxrkByQ@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2X5HYQAD13_Zt8cbZk6HPf6j-s8>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-compact-denial-of-existence-03.txt
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: Sun, 17 Mar 2024 23:32:31 -0000

Shumon Huque writes:
> The draft allows (but does not proscribe) NXDOMAIN to be inserted
> into the Rcode for non DNSSEC enabled responses. I guess the main
> reason for not being proscriptive was what I mentioned - there were
> deployments in the field that didn't. But I'm amenable to tightening
> up the language if there is consensus for it (and I'll also chat
> with the implementers). Since we also support signaled restoration
> of the NXDOMAIN RCODE field for DNSSEC enabled  queries, I'm
> persuaded that we should probably close this divergence for non
> DNSSEC too.

You already know my position on this, but for the list: yes, please,
do this.

The existence of some deployments that currently do otherwise is
insufficient reason on its own to not specify better behavior.

v2.23.0 | Report a Bug | By Email