Re: [DNSOP] draft-ietf-dnsop-extended-error status

Vladimír Čunát <vladimir.cunat+ietf@nic.cz> Wed, 02 October 2019 06:42 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 C1B8D120232 for <dnsop@ietfa.amsl.com>; Tue, 1 Oct 2019 23:42:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.998
X-Spam-Level:
X-Spam-Status: No, score=-6.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gnei4s21LHL6 for <dnsop@ietfa.amsl.com>; Tue, 1 Oct 2019 23:42:45 -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 DD2B2120025 for <dnsop@ietf.org>; Tue, 1 Oct 2019 23:42:44 -0700 (PDT)
Received: from [IPv6:2a02:768:2208:ed02:7285:c2ff:fe3a:c784] (unknown [IPv6:2a02:768:2208:ed02:7285:c2ff:fe3a:c784]) by mail.nic.cz (Postfix) with ESMTPSA id BA9A313FC6D; Wed, 2 Oct 2019 08:42:41 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1569998561; bh=LN0MJ/otEgjAkhgAD/2KnpcMQ9nohpbxTKfVh5+6KS0=; h=To:From:Date; b=kM2KDXEDyCRP3H0NL7F66vdmxxpPtFZPgwo6f156DFWszrI42ow0xtOXcYKxBAITG ZttstpnmaLPQgGz/KY6Dtns4colzl5iKzVmq+HOIEYaDmkmm0RxiBaLhtUYV1WQPHd qDgcNbaE2rZRdNVVy0hBHGeDDpmM3SuPcYxwd/kI=
To: dnsop@ietf.org
References: <ybly2y9z4v4.fsf@w7.hardakers.net> <alpine.DEB.2.20.1909301247550.11804@grey.csi.cam.ac.uk> <CAHw9_iJbOZ1kNNK_GpnVbVfFmkzB9dA3Sve0dXbz1bQK9+=1Ow@mail.gmail.com>
From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <vladimir.cunat+ietf@nic.cz>
Autocrypt: addr=vladimir.cunat+ietf@nic.cz; prefer-encrypt=mutual; keydata= mQINBFgDknYBEADHEQwLBlfqbVCzq7qYcBFFTc1WCAFtqiKehOrsITnKusZw4nhYwlKQxcum gj01xJOhbfHBCBeGlDydYqemKg4IfY2nwSyPwZZYMJn7L7AGrCeytr4VMvDJ7o7qDZjjim4i fv+GUwdk3plXx6oMF4nctesI8aAOuLUHAn0PfrGfNhWoaglOKgdOI6DGjhI/aGkvy+jrI/+X sdMV+3f1RuEOfI+Yu4SXFjJyhAmqEOBRxxdHqKreIIpz3Lg38yWwiVGfwgQT+nFIz9BpHH3l Wg1uS8xM3ezceBmRYV8zT9PvbeZ57BlaTR6rLae5RYwV397PSLBqqLkB5H0TDRUFBnwBsUob LebYHmJCOydvyNv5AFkLmLZ7O4j2jFo1WPSMt3ThM6wRwqrnB4Gi+6onyrZfE1DnVZMqbxZ3 VXa+E4S5YwrfCLUErGEn+d40OtoRZmQXhRPVAsdjimMj9oFM9RoxSgUrDg6Ia3n0IrKFb++z HAFbqkR5g4qzXiOMEG621GYEex2sDEKz/PD4CVKlNI9eld4ToH592kAwzJmd+sAi+Rfos0NE zxuFd0ekAOeWoURo0zoYTSWPlMOmFMvcpH6LP3leJmY7x4z/b1ng/+7UnKonVALVPFbRbElO kIfAtLKcUEofwV1jr7DyYGPalJtiDJPomB041ZHCj2RxyXY/oQARAQABtCRWbGFkaW3DrXIg xIx1bsOhdCA8dmN1bmF0QGdtYWlsLmNvbT6JAlcEEwEIAEECGyMFCQlmAYAFCwkIBwIGFQgJ CgsCBBYCAwECHgECF4AWIQS2AGRgtgqA54IGJEnnR98flXWjqgUCWg3w3gIZAQAKCRDnR98f lXWjqs7GEACZlVtvy0Q45DrRQJ2B5SAeb0ZJ5OZQFPFnnl4UjL2Q9A1jglzjftbhjfwf41K9 ouUoa6R8X8nlpGwo8DSZwXNYni8AXUMYh01VgSFop/6Uxeaczyz+X6/YJ5Q+UMEkVz2rrezp ZXG8pj0+yf8fGbImEqGDJInQZoJhUDaaFSiyFIMJWQUE52O117fAUvDDfVdvg3PDjaR+Mqf9 w6bZNm6Sr2LCJrxTLr71PcpZC0nD0menvUkAzwe4BzVmciSZWtyQB0fhlr6cBGb0WpqgYlXO V0TecMtAZGKrzsT48fspeBGPPobW9t6YsnFgQQB1V3ON4VxHxDeD3OV9Aq91zLl1cgBmp/z6 5APzzqHXthX/meBCzKLO06w82Np/gIeksFA05HbbykZElslbB2eFz8W3tV4WLWcKucDPl+Pm zlbt8XprWE7Pyn6mFp8beZQWT0VOcSTH/UOfEImplxFLRDTLk0wjMye/i06XlPu/1nrditHw mlVjFbdc7NSiO8rXdUgTuOEwdZMyIhCB9SWNxZa+7F3kVKdXTBytVaYSfD3qoDBP8bhaeDF8 K6054uo5pmBXD2f8WGqbuikNh64i1oncmj475uxRKkzByrkY9XN9qRKjWav6/ZemxMRgGmV+ HHef8lhyLthDvucIEHELuRK+xWmcD4fn5Mhk4DN4LLezwrkCDQRYA5J2ARAAyHww3huLEtsd yqgjiGMhtEKOLmp7yFl450HY9oPcHS02U5BC1370ssNShrdOCi2ACDbe41Zxx85WcuaO1OVq ung2umX047mj2xQsiTAFRDLZsQu8cQFoEy/DBL2bk7ThfK1Lh+NyZAs0UaPpDkGodS0De9os A+4T6Nf4POYaeavbYVFSdDKS4lUboBqApKnD/TzKFxFcpuFx6FN92lteTbOojGMiLoZvELY8 6Kn9KuFZ8FM2ZSNHx1Z75KouufGrdkeCoZYVYiuzT+fnt2it4dIpIlnF+yxMt5LB/MSrmECB 5CAFJtxzuMccm6yDUZQSWWi9vUgxIJwvt5w0CIBT353DGeP4WnH0r5YoBKoRbh7i4fT0lWvM XTG/V2lqyzBdClMebyHffMgba26Kj6oeDygDfC5aGsVaqw1Ue/qQ5QRqTJcJV7xVLTtS1Eam VqkfKwPS0zTfnrF1jQtnO/P4qkfgBRRG9BXGGrykHpXOyqmX6Z0wbV2P4j+p02oSecDl5yVX plJfsXfbS/xXnaSkaN/7mCU29ul26cAVNxDkDPunztSFi9K9LM2T/XWYJQGXM71OpmONQJGF 24lx7Wp/kobnHtbjGDzjDPC4eSL7MA56qtrWaLM+4ePKANct2q0q6c0uSLs0Q2zochS64Mcg 0YzL1sinWPN1rXLDk3lwpIsAEQEAAYkCJQQYAQgADwUCWAOSdgIbDAUJCWYBgAAKCRDnR98f lXWjqn4yEACA0f1XBAg+WMaNPtIt0k15yFPfhdbOg9GhDcYGgvFIOxRuaFWw9SLUt7OGuUnI pKxKRXtQJss98fHkijo70ONYWPuLhfRGK/wg9Ao6MuFw5G8m431CBS/awrieb6iPjvAARXJC PTTBZk/NC988jiKdCh8PbTCHDsl+gSDytP15QUrdqSfS2Wf4653ej7+jtuTjxZzmGgvNSi6J Dlb9KNtmBQKQAgpnOQM46ItESmzHDnmdcvhPLUDsjwkpIJ6clasOzaObwxJiba7iFPcGwcCl CSwYjMNXFtneCGUnEAa5RBIx+i+LV1iqB3VRvTC6tMIUueoQ7cdTy6afNkhwQYXm4/pDmNT8 UMdnzwnlTpFQ0CegDQRDWc+dIDDBHGEEEYBh2vTOE04KrmYUp1bQsNegPfvLwoHib0jEvohP MJ2fJtZAd1SJElgwPbM8H7emKBiTsHwF8gL7G2jo7AoGpqYjqXkCRS0tSLTNr+qHh+7Ltrkb u/ZVTTfh4Q/qw3VaLYQh4C0tBma/YevQy1O2c3TZXXFz1QF8b9/Hj/3sq2KgT1AcZ51E+xG+ cb6cUqgkihmgm39xx24GPlNAdCRuq01+iILol+Wox6OwF6hmqx1EMSmxcmGoUREr0rkMnFVs WeAYeVoE4q689qxCPu9iCMJMJnkRe1o9oQYSN7my+S98gA==
Cc: Warren Kumari <warren@kumari.net>, Tony Finch <dot@dotat.at>, Wes Hardaker <wjhns1@hardakers.net>
Message-ID: <6826fd77-6b75-f656-962c-3e09bda1705e@nic.cz>
Date: Wed, 2 Oct 2019 08:42:41 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1
MIME-Version: 1.0
In-Reply-To: <CAHw9_iJbOZ1kNNK_GpnVbVfFmkzB9dA3Sve0dXbz1bQK9+=1Ow@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.100.3 at mail.nic.cz
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/A8-xAIEbywBXO2CO-OHlhLXj5fs>
Subject: Re: [DNSOP] draft-ietf-dnsop-extended-error status
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: Wed, 02 Oct 2019 06:42:48 -0000

On 9/30/19 11:47 PM, Warren Kumari wrote:
> On Mon, Sep 30, 2019 at 7:54 AM Tony Finch <dot@dotat.at> wrote:
>> Difficult. In general there will be multiple upstream servers, even in
>> the simplest case of a stub talking to a recursive server talking directly
>> to authoritative servers. So there can be an arbitrary combination of
>> upstream errors, and they might not relate directly to the QNAME, (e.g.
>> problems with a parent zone, problems chasing down nameserver addresses).
> RFC 6891 - Extension Mechanisms for DNS (EDNS(0)) speaketh thusly:
>
> "EDNS is a hop-by-hop extension to DNS. This means the use of EDNS is
> negotiated between each pair of hosts in a DNS resolution process,
> for instance, the stub resolver communicating with the recursive
> resolver or the recursive resolver communicating with an
> authoritative server."
>
> and also sayeth:
> "OPT RRs MUST NOT be cached, forwarded, or stored in or loaded from
> master files."
>
> I *think* that this covers the issue for many cases; EDE is not
> intended to be a silver bullet, more something which provides useful
> information for troubleshooting / debugging.
> We would not (and cannot :-)) preclude other work from further
> defining this, but I think that it's beyond the scope of this document
> / we will better be able to understand things once we've had some
> deployment experience.

My understanding is that the hop-by-hop condition is just the default
and as suggested we could define/allow e.g. that if all upstreams return
"filtered", we send the same downstream.  I expect we could first
publish RFC without propagation of these errors in mind, but there's a
risk that when we later want to add that, we'll need to make too big
changes, e.g. we may miss something like the near/far flag mentioned
earlier.

If we/you don't want to deal with the propagation now, reserving some
bits for future use (MUST zero now) might be a nice compromise, assuming
we at least have some vague idea that a few of them are likely to be
useful in future.  Another plan might be to do nothing now and later we
might: (1) define another EDNS0 extension that will *separately* carry
information in addition to this EDE or (2) define new flags within the
current EDE and utilize the allowance of sending multiple EDEs.  These
options sound a bit messier to me, but they seem doable.

--Vladimir