Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-00.txt

Vladimír Čunát <vladimir.cunat+ietf@nic.cz> Tue, 26 October 2021 10:25 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 5DA063A0DCE for <dnsop@ietfa.amsl.com>; Tue, 26 Oct 2021 03:25:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.23
X-Spam-Level:
X-Spam-Status: No, score=-5.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpdaXVoigih9 for <dnsop@ietfa.amsl.com>; Tue, 26 Oct 2021 03:25:35 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 70E073A0DC7 for <dnsop@ietf.org>; Tue, 26 Oct 2021 03:25:35 -0700 (PDT)
Received: from [IPV6:2a02:768:2d1c:226::a2e] (unknown [IPv6:2a02:768:2d1c:226::a2e]) by mail.nic.cz (Postfix) with ESMTPSA id E7B4A144D89 for <dnsop@ietf.org>; Tue, 26 Oct 2021 12:25:22 +0200 (CEST)
Message-ID: <e39ebf5a-f2a9-62bf-2a92-db97b122fafb@nic.cz>
Date: Tue, 26 Oct 2021 12:25:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.1
Content-Language: en-US
To: dnsop <dnsop@ietf.org>
References: <161953482575.7668.10479553059119648994@ietfa.amsl.com> <f3fca741-373e-c32d-9dbc-354cff3dfc9b@nic.cz> <D2793C49-7951-494F-9B7C-CA7E0BD7619B@dnss.ec>
From: Vladimír Čunát <vladimir.cunat+ietf@nic.cz>
In-Reply-To: <D2793C49-7951-494F-9B7C-CA7E0BD7619B@dnss.ec>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.102.4 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/hlbd6GwIzxdNXsN-Q9S5dW6ZO7E>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 26 Oct 2021 10:25:37 -0000

On 26/10/2021 12.10, Roy Arends wrote:
> I have a slide ready to discuss the issue that DNS Query Name 
> Minimization brings… A minimised query can’t be distinguished from a 
> full query, so it may not be clear what name caused an issue. The 
> current thinking (but will be discussed later today) is to start with 
> _er as well. That way, the erroneous qname is “encapsulated” by _er 
> labels.

I assumed you can distinguish those quite reliably thanks to QTYPE=NULL 
which I haven't heard of for minimization so far.


> If, at any point, auth servers offer encrypted transport, a faulty 
> query should not be replicated in clear text.

I certainly agree with that, but then the text should be clarified that 
the encryption refers to auth side and not client side.  As it is now, 
it refers to RFC numbers that explicitly consider client side only, so I 
assumed that's what was meant.


>> To make the error-reporting work, you need noticeable commitment to 
>> deploy on both sides, because otherwise the perceived benefit from 
>> deploying might be quite low.  On resolver side, I believe that it 
>> will be quite rare for operators to tweak such highly technical 
>> options[*].  So if this MUST be off by default, you at least need 
>> commitment from some significant operators - say, I'm not even sure 
>> if Quad9 by themselves would suffice to bootstrap this.
>>
> I'm inclined to remove that text alltogether. Resolver implementations 
> either do this by default, or not. No need to pedantically require 
> config first and default off. Additionally, there is an issue where 
> resolvers need to retry without the option when auth servers can’t 
> handle the option… I’m inclined, just like Extended DNS errors itself, 
> to have authoritative servers just set the option, unsolicited. It 
> hasn’t caused any issue for extended DNS errors yet… but lets have 
> that discussion this afternoon.

I'm not sure about this reasoning, but anyway - I'd be also inclined to 
remove that paragraph, and we'll see what opinions appear during the 
call and afterwards.