Re: [DNSOP] Murray Kucherawy's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)

Vladimír Čunát <vladimir.cunat+ietf@nic.cz> Mon, 16 May 2022 14:15 UTC

Return-Path: <vladimir.cunat+ietf@nic.cz>
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 7EFD9C185B26; Mon, 16 May 2022 07:15:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.957
X-Spam-Level:
X-Spam-Status: No, score=-3.957 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, NICE_REPLY_A=-1.857, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 6VkKMLo_6XtZ; Mon, 16 May 2022 07:15:18 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2573C180A91; Mon, 16 May 2022 07:15:15 -0700 (PDT)
Received: from [IPV6:2001:1488:fffe:6:254d:255b:b488:9573] (unknown [IPv6:2001:1488:fffe:6:254d:255b:b488:9573]) by mail.nic.cz (Postfix) with ESMTPSA id CF0BF1405A5; Mon, 16 May 2022 16:15:11 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1652710512; bh=6ma07PMHZvayOWUWg3DJ5RPQzJyfQZmom8vBg7DBCHo=; h=Date:Subject:To:Cc:From:From; b=pqqj2DlEuWpy1q25ZlB8tbBroF5MDPnJMenvt2dZqmgpMN9KcRwm6GUwxqGyGz7se FbjQ4XznH6zVnEXPXXLqiAjeL8ES978E/l47/QTo5dduQe6I4A8tCKioy0Q3he80cA D7AvR0gCuXn2gj4b8RCFLxHPcTsmcTXmhuGBxuAs=
Message-ID: <2520b3f8-d7bb-0dee-ce55-953451e0f168@nic.cz>
Date: Mon, 16 May 2022 16:15:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1
Content-Language: en-US
To: Murray Kucherawy <superuser@gmail.com>, The IESG <iesg@ietf.org>
Cc: draft-ietf-dnsop-nsec3-guidance@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, tjw.ietf@gmail.com
References: <165221253037.14194.8564840834151465618@ietfa.amsl.com>
From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <vladimir.cunat+ietf@nic.cz>
In-Reply-To: <165221253037.14194.8564840834151465618@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.103.4 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/xTiuWEQ5j-MsPpQWzT4ZhhBJCNI>
Subject: Re: [DNSOP] Murray Kucherawy's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.34
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: Mon, 16 May 2022 14:15:22 -0000

On 10/05/2022 21.55, Murray Kucherawy via Datatracker wrote:
> Regarding the SHOULD in Section 3.2, what other action might a resolver
> legitimately return, and why?

Extended errors (RFC8914) generally aren't "mandatory", so they may 
return none.  In practice I also see quite some leeway in which EDE(s) 
to return, because there are more complex cases than matching a single 
one and implementing everything precisely might be very difficult.  (For 
example, one error got encountered and then the resolver retried against 
with a different RRSIG record or asked a different server and got a 
different error or none.)


> Same question for the SHOULD in Section 4.

Here it's a tradeoff, and not all operators/vendors will have exactly 
the same view.  Some are very sensitive about producing "unnecessary" 
resolution errors (SERVFAILs in this case) and are willing to pay by 
(possibly) doing more CPU work, etc.


--Vladimir | knot-resolver.cz