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

Puneet Sood <> Wed, 23 October 2019 01:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C4DC912022C for <>; Tue, 22 Oct 2019 18:55:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BdbbpVzItzE9 for <>; Tue, 22 Oct 2019 18:55:24 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::a34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 06FAC120026 for <>; Tue, 22 Oct 2019 18:55:24 -0700 (PDT)
Received: by with SMTP id j22so956348vki.9 for <>; Tue, 22 Oct 2019 18:55:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=vhWd5rTHkLKvn0RSYuG7XJTRI/OEaUVdywQ7DDA8W9Y=; b=Fqxl7dFbwH8txVXjQ1l9Tj5112P6hAW0RikGknuCs35b/alrIzpkhMWRxNI1Ird7f5 NFIVwkHJJSH71ZdqNpfdTVcMDlqxajsF4klLeRRC8HLa9oLe36+OVT2zjmiHguUQBNgR aFjkULsnNURKIi8l23zAs+gg25UXfAatVOH+rcszmgGz17qzxqyaFfS22oF8swd9ACdq m8dQp3/3geE7oU6voneIJ6zz81S347VxkVvykF2C5rbgd7zah1p/UbbfeSNmDk1DExNf 5toromSyIFupdqojVaFlKqd9wozNRmuf66i7BTMzQ47nAvoHfNJNTrvbk548KR1CY2W4 pJsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=vhWd5rTHkLKvn0RSYuG7XJTRI/OEaUVdywQ7DDA8W9Y=; b=kQYUIYSZqScrIYh2uJDWl0yST/yiZVG2xi/aK8xRxkPxd2pF8FLxT3cGd/5T0hu+Yb 8RKR3ci41aA9TcECkGeLPbxA5jD4h3HVXjF1wp2EFDxKiGdXUpwr19gTBqkqAcY/dXxY 3CsYGaHuvl05Uo4xdK+frgoBGgMODzJuo16IQYYIyEqfjRo9AZxW9HwNzYaJzvW1uesI 4yjAiByJI5/tQZUmQJpN4bZF4sVDxoSgywtSisYOcbU+5Egj1JpadmXq2PBq4eEjkCiu 9kjtNVU+ua7mauHXFiafV39D9FNz2oKZMHtWJ6hMObbAzp9u9tqGb/v2F3t4eQYb2MH8 osiQ==
X-Gm-Message-State: APjAAAVX3XqwavXDYxaCv0T7d+2c7M1TxsWk5W9sPU4kJggnXsnf+35L M8MSx5BmYt4mx2jzA2dNT1dF91vUcl7W2F1+uQfPEw==
X-Google-Smtp-Source: APXvYqzaEvSdiKnXxkI5m6YnYw+UPYgbNx7GO71LNNZFrGAhx0Zv13PohMtHHHp+0wsaAsS+ydpEYeGgBVfg0qQ94v8=
X-Received: by 2002:ac5:c645:: with SMTP id j5mr3896805vkl.93.1571795722446; Tue, 22 Oct 2019 18:55:22 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Puneet Sood <>
Date: Tue, 22 Oct 2019 21:55:11 -0400
Message-ID: <>
To: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <>
Cc: IETF DNSOP WG <>, Tony Finch <>, Wes Hardaker <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [DNSOP] draft-ietf-dnsop-extended-error status
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 Oct 2019 01:55:27 -0000

On Wed, Oct 2, 2019 at 2:43 AM Vladimír Čunát
<> wrote:
> On 9/30/19 11:47 PM, Warren Kumari wrote:
> > On Mon, Sep 30, 2019 at 7:54 AM Tony Finch <> 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.

To me the authors' consensus seems to be towards getting EDE into the
real world and learning from its experience to improve it/build
something better. That sounds like EXPERIMENTAL to me. That way
leaving the caching/forwarding behavior unspecified is fine. Based on
experience in the real world, we come back and define/implement EDEv2
and deprecate EDEv1.

Too naive?

For Google Public DNS, EDE or something like it which makes it easier
for users to self-diagnose problems with our responses would be a
great thing.


> --Vladimir
> _______________________________________________
> DNSOP mailing list