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
>