Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-error and combinations of EDEs and RCODEs
Eric Orth <ericorth@google.com> Tue, 17 September 2019 18:14 UTC
Return-Path: <ericorth@google.com>
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 5E09B1208F8
for <dnsop@ietfa.amsl.com>; Tue, 17 Sep 2019 11:14:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 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,
HTML_MESSAGE=0.001, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key)
header.d=google.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 XhGbNvFLeat1 for <dnsop@ietfa.amsl.com>;
Tue, 17 Sep 2019 11:14:06 -0700 (PDT)
Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com
[IPv6:2a00:1450:4864:20::443])
(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 87A1612000F
for <dnsop@ietf.org>; Tue, 17 Sep 2019 11:14:06 -0700 (PDT)
Received: by mail-wr1-x443.google.com with SMTP id o18so4133979wrv.13
for <dnsop@ietf.org>; Tue, 17 Sep 2019 11:14:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=z0hH6dNratMCrLjREVLL1EgDx4IXKWDd+jBOY2Qgeg8=;
b=YPQsy8CKLPQHb7Xd3pV7NAS2ErPPhQPkhCqpzzf3loFxnqwYkz9FHuW0jKBj3BJM1P
OkeJzQLGw8t5/PRnnWISC6cMle4NJTcrUtmjk4jgjdlTKScd0UIBtxWAie/QguevNJ82
tZAwOguUy91eNlrHCB/+UEI8I2aIGbi6qA9xF9Lw9XaFIFHxz5knEtKQeHElO2AhnAdj
mSx/HXc4pbo8//fG1WfR2HzRARI7OPoEiRb5DallEGlB9viK8TWl9Ey5jMtBYMBMgqyt
JrcTEMblNL9yToLUFrdNcdoNSNTq09vQ5794bAgTArUwQ0lASeYE2czMDnS4ICWJ4dh7
9Nug==
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;
bh=z0hH6dNratMCrLjREVLL1EgDx4IXKWDd+jBOY2Qgeg8=;
b=RqwN9Afc8wKz2kO31ZTylOz5GfwcXWdpF8b0eHpRXwUFhJOrGp1ZAfiUWxRczZkYW1
73Vly+huOj2/8jWrMKSPOPdn7FaouodaRHJFB1m4zaXrex36dqPd8ZGP3FMA7dNouM28
e5U+ZrIomtfzxoPKTuIrFUH7ziZuJuJN7jyMljh0Ut2QEv9fLy26A6462Ts8qQupEkV1
f7o9Q1v/abUkKRlst37+fcub9pmj5CrhXyMsSg8pLwoskDEx/slHQVpj5Q/ljyMtegKL
xmOju9Wpzba0r0A4lb2CxyZV8oDOHKJ23+gh22LFE5MV1hvko0XcyR3cabrchIwc/TE+
xs5Q==
X-Gm-Message-State: APjAAAXYw/PzzSYAWDwdGoSPRZ5tUjHfWxp12O/4NmvtMTLaia+F5EiL
fGXRll6DAJuYaPpYTd979UmYzDAfFoVaMAIZiGrfxLHiSR83aQ==
X-Google-Smtp-Source: APXvYqwpgUiAiKLATzcC1tIqv7+TamWQuysXp965aHKP1/101tyFS4V1smq+28pRcg3botRdUq04vT8oGoe0R/1jtDw=
X-Received: by 2002:adf:ef12:: with SMTP id e18mr3946284wro.65.1568744044452;
Tue, 17 Sep 2019 11:14:04 -0700 (PDT)
MIME-Version: 1.0
References: <EA557043-34D1-43EA-B750-4A17CFC6BE50@icann.org>
<ybl36h4aj8x.fsf@w7.hardakers.net>
<AFE92D06-8418-4451-A827-D5656C83B796@icann.org>
<yblzhjbeova.fsf@w7.hardakers.net>
<067589D2-8E7E-47FA-867C-72E266A55D6D@icann.org>
<CADyWQ+EB-eotvTdYwNv5Oo4=-mibdgEgpkQ3yh37orAwp-AgWg@mail.gmail.com>
<ybly2yubfnp.fsf@w7.hardakers.net>
<21136294-FDFD-4A99-9529-E79C45E79535@icann.org>
<yblzhja9kz3.fsf@w7.hardakers.net>
<3AC375B1-D858-4577-AEBE-4BB7CD40C241@icann.org>
<1878161734.14716.1568306548325@appsuite-gw1.open-xchange.com>
<0C5DC6B2-E9C5-46A6-B0BA-12830A405DD2@dukhovni.org>
<d4b78f2c-9c0c-d144-a351-2961bd66f4d9@nic.cz>
In-Reply-To: <d4b78f2c-9c0c-d144-a351-2961bd66f4d9@nic.cz>
From: Eric Orth <ericorth@google.com>
Date: Tue, 17 Sep 2019 14:13:52 -0400
Message-ID: <CAMOjQcHabPQpGNtCdAh0SYp+AFAKJ3Lf=MHJN-kwR8zQzuZLWQ@mail.gmail.com>
To: dnsop@ietf.org
Content-Type: multipart/alternative; boundary="00000000000083c7cf0592c3af81"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GTg8wa7lQ-VoBFcp_P5tT4VuQhE>
Subject: Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-error and
combinations of EDEs and RCODEs
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, 17 Sep 2019 18:14:09 -0000
Any suggestions of making absolute requirements of how the application "acts on" EDE codes sounds way too restrictive to me. Most of how the application acts on any error codes is up to the application, and it would be unnecessarily limiting to pretend otherwise. Seems to me it would lead to silliness like "this application processes SERVFAIL by sometimes continuing to other servers and sometimes not" and then claiming they aren't changing that processing by using EDE codes to determine the actual continuation behavior. Specific thoughts: *The text currently in the draft ("systems interpreting the extended error codes MUST NOT assume that a combination will make sense") seems reasonable. Not overly restrictive. Just a reasonable warning of a potential false assumption of how the recursive resolver may act. *Something like "applications MUST continue to follow requirements from applicable specs on how to process rcodes no matter what EDE is also received" also seems reasonable. Clarifies that those cases where requirements do exist on how an application acts on errors still apply but doesn't pretend that the EDE spec now tells the application what to do in all cases. *Something like "applications SHOULD interpret EDE as supplemental to rcode rather than as a replacement" also seems reasonable. Clarifies the communicated meaning of the code without over prescribing how the application acts on that meaning. *Something like "applications MUST NOT act on EDE" or "applications MUST NOT change rcode processing" does not seem reasonable to me. Way too unclear what "diagnostic" processing is reasonable and allowed or not. And potentially limits applications from doing processing based on very reasonable or obvious interpretations of the received rcode/EDE combinations. On Mon, Sep 16, 2019 at 11:20 AM Vladimír Čunát <vladimir.cunat+ietf@nic.cz> wrote: > On 9/12/19 8:10 PM, Viktor Dukhovni wrote: > > SERVFAIL means, and will continue to mean, I can't help you, better > luck next > > time (or elsewhere). > > > > The new EDEs are *diagnostic* detail to aid in troubleshoots, but do not > > override RCODEs. They are not a more fine-grained RCODE one might "act > on". > > If we want more fine-grained *actionable* codes, there's plenty of room > for > > more values in the 12-bit EDNS RCODE. > > > > [ I chatted off-list with Wes, the above appears to match his take, with > a bit > > luck also rough WG consensus... ] > > My understanding was that it was meant for resolvers to change e.g. > their retrying behavior based on the EDEs in some cases, even after > removing that "Retry flag". I did consider that a significant part of > the (original) motivation, even we did not implement that in the first > prototype (as only server-side was done). > > I certainly agree this issue should better be explicitly stated in the > final text. At least assuming the WG consensus will be that they don't > want resolvers acting on the EDE codes in any way except for diagnostics > (possibly with RFC2119 qualifier). > > --Vladimir > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
- [DNSOP] Comments on draft-ietf-dnsop-extended-err… Paul Hoffman
- Re: [DNSOP] Comments on draft-ietf-dnsop-extended… Wes Hardaker
- [DNSOP] draft-ietf-dnsop-extended-error and combi… Paul Hoffman
- Re: [DNSOP] draft-ietf-dnsop-extended-error and c… Wes Hardaker
- Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-e… Paul Hoffman
- Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-e… Tim Wicinski
- Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-e… Evan Hunt
- Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-e… Paul Hoffman
- Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-e… Wes Hardaker
- Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-e… Paul Hoffman
- Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-e… Wes Hardaker
- Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-e… Paul Hoffman
- Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-e… Vittorio Bertola
- Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-e… Viktor Dukhovni
- Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-e… Ray Bellis
- Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-e… Paul Hoffman
- Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-e… Viktor Dukhovni
- Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-e… Tony Finch
- Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-e… Vladimír Čunát
- Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-e… Eric Orth
- Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-e… Wes Hardaker
- Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-e… Wes Hardaker
- Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-e… Tony Finch