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

Warren Kumari <warren@kumari.net> Mon, 30 September 2019 21:48 UTC

Return-Path: <warren@kumari.net>
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 54637120170 for <dnsop@ietfa.amsl.com>; Mon, 30 Sep 2019 14:48:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 qb4c_lzzIZRJ for <dnsop@ietfa.amsl.com>; Mon, 30 Sep 2019 14:48:11 -0700 (PDT)
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4AEA12013D for <dnsop@ietf.org>; Mon, 30 Sep 2019 14:48:11 -0700 (PDT)
Received: by mail-qk1-x731.google.com with SMTP id y189so9272682qkc.3 for <dnsop@ietf.org>; Mon, 30 Sep 2019 14:48:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fXRe9rjEIFFfp8CGNvc6tdISafSHN68Sa3dwGx7cDlA=; b=jzC4FMIAXwfNA/RvL7ROiYY4Rb2KwOh3adCYrTfSZLQ0wiZtKscjiwPr8y5mODUh9j x/VSQXwpDtDgCEbrUNzNgRyNBQS4LDoFc4RekAz30CFBO/Udm354mypsgD0NO8J5U0eI XiG3++/z5JlQ7EIPdb40BY3OYSGQpxuww9Thsk87KiQJqesTblCiN8imdYrxJCSjqdYi g07p4KJOqY/aXm59l7ONRAfySE2UGjeLvARV1ugcAWYwjzExi1pJtaJ/0mSc54KCvp5O 02SdCJXGU1Q+steV0tBSJqoCL8Rrh+6cuDbLq6VsLeckYJ8XYxNJgKLBvjudM/VkIhoN kUXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fXRe9rjEIFFfp8CGNvc6tdISafSHN68Sa3dwGx7cDlA=; b=NUB03Rq2L4Q+7tGNR18BHiL9YJeMu7kzMnWdJ9JiDRhLfCMSMEVsywxVU8O+B2go1Z 3pcIXgFnENQfAMyQ8fWsnznEdWT7kMfWpjY4l65HRPJyekweIa1IhFug9c1YhTYxZTSI GcGa37vQby9aDGCvtyk5M5k1ZQ+9+uNLr9zdVYslxyKNRzzllHA1F+JboAvMvXhDzqgD jimgPx+6aiCCrMGGUhaoi5G/OD3jEftnqXJOgRpMNHpgohkXWT4M9pgcT4cPFon8ZDM2 Zn1FE/RcvRWBUQEqI3PQrWbaA6WQwxuU7NWHyLEVk8c2kd6euSJGekcIpzDt0O12zqj4 Dsrg==
X-Gm-Message-State: APjAAAXoTIGTKv0a3NsQRccdr5Hr8pNWEJ6gvXCXjRGmTj6ziZBXimZ9 Amq5JFiEVDnVRLIDNA1l2F/I2iCZ+gq5EumKrj1Gc7cyths=
X-Google-Smtp-Source: APXvYqxaoVLta1kWCMeBrDr+KIspFirH5W+HTOqRtN8FnShmMRkjFzfqN1C8YxML/9ahxtQkEOtYduvPK1KP+hX9Q3k=
X-Received: by 2002:a37:a849:: with SMTP id r70mr2486454qke.37.1569880090057; Mon, 30 Sep 2019 14:48:10 -0700 (PDT)
MIME-Version: 1.0
References: <ybly2y9z4v4.fsf@w7.hardakers.net> <alpine.DEB.2.20.1909301247550.11804@grey.csi.cam.ac.uk>
In-Reply-To: <alpine.DEB.2.20.1909301247550.11804@grey.csi.cam.ac.uk>
From: Warren Kumari <warren@kumari.net>
Date: Mon, 30 Sep 2019 17:47:33 -0400
Message-ID: <CAHw9_iJbOZ1kNNK_GpnVbVfFmkzB9dA3Sve0dXbz1bQK9+=1Ow@mail.gmail.com>
To: Tony Finch <dot@dotat.at>
Cc: Wes Hardaker <wjhns1@hardakers.net>, dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/hy2-h7kXBD8OjopnmzCJKQgWPi8>
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: Mon, 30 Sep 2019 21:48:13 -0000

On Mon, Sep 30, 2019 at 7:54 AM Tony Finch <dot@dotat.at> wrote:
>
> Wes Hardaker <wjhns1@hardakers.net> wrote:
> >
> > 2) One outstanding topic of discussion that I think we need to decide to
> > handle or table till a future document: how do we handle forwarding,
> > chained resolvers, and caching.
>
> 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.

Thank you,
W



> Perhaps if the upstream problems are consistent with each other, the
> resolver can return a single extended error code to its client; otherwise
> fall back to a "multiple errors" catch-all?
>
> Tony.
> --
> f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
> Malin: East backing northeast 5 to 7. Moderate or rough. Showers. Good.
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf