Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 365631200CD for <>; Tue, 22 Oct 2019 18:49:31 -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 Ts2rUrCkN6df for <>; Tue, 22 Oct 2019 18:49:28 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 64F69120026 for <>; Tue, 22 Oct 2019 18:49:28 -0700 (PDT)
Received: by with SMTP id l2so12701180vsr.8 for <>; Tue, 22 Oct 2019 18:49:28 -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; bh=mliB3Gi7ZG9VinUM7jrT3XjOfQP6atoRIe4TyeY1WN4=; b=mrNZpvAjX2nLOpGhTW75iiW8FR27qeKzG4xupoITpBYTu/wYmfr2og/DxlE7EQ5Nip /a2/qPPMKjT32bmNZPxipKKd1DCjY7e3oMvppVBzI1EbqKUuh16rZACoXDWSD4nqPr7B iNVeUh8w/FrRuoryvfWl66nGzAn2cDMknowjioJ7ye+eTaCz4vKwTAPZ3XsHgOpvOds8 pZpt9iKu0tz61VJlnBtTXD/AlBS2MBaGJ2IUdydd97AANwh4ZrUUAW/YVXOe1yUiJM8K S1lyYdkHrT5Wink6yKM2qhMnVsYrG9UVonYcMihnSg1dZHL7M5yr78Sq1MIHEPk/Ct8/ IH/A==
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; bh=mliB3Gi7ZG9VinUM7jrT3XjOfQP6atoRIe4TyeY1WN4=; b=CtLU49dwvBQjvqksqiYnFbFGqbqrgBG8C8AibpCGvxuEb/2m72IWAl0Y3WHNgPUndO v61GTloBchJT1VTX0/fdsPTsN4/3XkrJTH201HC7XaCo+7LkmIdmzosEM+DKUldsU61D BGtVVDYdxJg7aCusfH2NaV4WBAbnvtNkhQDbQ20DEF/XZYNV2ldeUhNXHXAtesc0And2 KaJMrwvMBK4m2i4M+/Tvu/GwkC/FSlWtUAKdY1uVtPDpw6x8W4IZVc1YzsIsxr3NeOH/ 0b8wDvHGhuvdpTuN8MkLWr8AX5ljONELWWvVrh9pwpd40nGXJinFnOOItu4rbul5jzPC AsJQ==
X-Gm-Message-State: APjAAAWQujdz7sH528DamSMRcPm0NvWGTR17PZ6lgBWjuhBmFzzLiBK4 Zze91I4k3NcznLx/Snz+kMAbBOLGyC8lJP57c8kc3sVd
X-Google-Smtp-Source: APXvYqwzbxEX+bMpmLzToOzZ0j3M/y5cFvw7BqllgE9wi6D7Xiksd9Z8EQ8Q20UnrTRn9UXg5CvfOyutKCky4usBpQU=
X-Received: by 2002:a67:be19:: with SMTP id x25mr3825627vsq.51.1571795366720; Tue, 22 Oct 2019 18:49:26 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Puneet Sood <>
Date: Tue, 22 Oct 2019 21:49:14 -0400
Message-ID: <>
To: Wes Hardaker <>
Cc: dnsop <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error
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:49:31 -0000


I read and diffed version 12 but did not find text addressing some of
my comments.

On Fri, Sep 27, 2019 at 7:41 PM Wes Hardaker <> wrote:
> Puneet Sood <> writes:
> Hi Puneet,
> Thanks for the comments.  Responses are inline below in my tracking
> notes below.
> 14.5 TODO Puneet Sood
> ~~~~~~~~~~~~~~~~~~~~~
>   I got around to review the draft only recently and have made an
>   attempt to avoid points of discussion that have been resolved since
>   IETF Prague. Apologies in advance for any duplicates.
> * DONE 1. Introduction and background
>   Para 2: "A good example of issues that would benefit ..."  Comment:
>   The paragraph leads up to the conclusion that the EDE codes will be
>   helpful to a client to decide between retry and stopping.  Since the
>   consensus is that the EDEs are purely diagnostic, it would be good to
>   reiterate that at the end of this paragraph.
>   + Response from Viktor: For the record, while that was
>   "diagnostic" was my take on the purpose of these codes, reading other
>   responses, I am not sure that's yet the consensus view...  I could
>   also live with these being actionable, provided the text is then more
>   clear on how to do that correctly
>   If the actions based on these codes are arbitrary choices for each
>   implementation, with not even a clear correspondence with associated
>   RCODEs, that feels like too much rope to me...
>   Eric Orth's comment from Sept 17 is also relevant here (no one has
>   responded to it yet). Quoting the last bullet from his response here
>   for reference:
>   []
>   *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."
>   + Response: Paul H. gave us language to put in both the abstract and
>     introduction to address this.  Let me know if you think it doesn't
>     address this issue.

> * TODO 2. Extended Error EDNS0 option format / forwarding /etc/
>   Final para: "The Extended DNS Error (EDE) option can be included in
>   any response (SERVFAIL, NXDOMAIN, REFUSED, and even NOERROR, etc) to a
>   query that includes OPT Pseudo-RR [RFC6891]. ..."
>   Comment: Given the level of discussion around behavior when
>   sending/receiving the EDE option, there should be some more text
>   giving guidance on behavior.
>   a. For recursive resolvers, it may be worth pointing that it is not
>   expected to copy/forward EDE values received from authoritative
>   nameservers to their clients.  b. What is the expectation on caching
>   for the EDE code generated by a recursive resolver in response to a
>   query? My expectation is that it will be cached (if the answer itself
>   is cached) so the next response has the same EDE code.

> c. Truncation:
>   In case a response including the EDE option with EXTRA-TEXT filled in
>   exceeds the effective UDP payload size, what is the desired behavior
>   for the EDE option? Should the EXTRA-TEXT field be left empty in favor
>   of filling in other RR types? Should the response be marked truncated
>   to require a re-query over TCP?

Independent of the decision on EDE forwarding and caching, the I-D
needs to have some guidance for it. The EXTRA-TEXT field may be
obtained from configuration and it is possible that the resulting DNS
message will exceed UDP message size limit in the request.

>   This is unlikely for failures but could happen when DNSSEC validation
>   could not be performed due to unsupported digest type.
>   + Response: good questions, and I think the WG needs to think about
>     whether to add that much more data.
> * DONE 3.14 Extended DNS Error Code 13 - Cached Error
>   The resolver has cached SERVFAIL for this query.
>   Comment: To match the text the name should be "Cached SERVFAIL".
> * NOCHANGE 5. Security Considerations
>   Para 2: "This information is unauthenticated information, and an
>      attacker (e.g a MITM or malicious recursive server) could insert an
>      extended error response into already untrusted data ..."  Comment:
>      Agree with some other comments that this is not relevant since no
>      action is expected to be taken based on EDEs.  Comment: There are
>      ideas in the thread to have links to info in the EXTRA-TEXT and
>      possibly display it to users. I guess the usual warnings to not
>      click on potentially unsafe links apply.
>   + Yeah, it really would be remiss to leave out that point.  There may
>     be nothing we can do, but the whole point of a security
>     consideration is to properly disclose any known threats/issues.
I do not see text mentioning this.


>   Thanks, Puneet
> --
> Wes Hardaker