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

Puneet Sood <> Fri, 20 September 2019 21:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC347120114 for <>; Fri, 20 Sep 2019 14:17:19 -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 1440C3wMKO7b for <>; Fri, 20 Sep 2019 14:17:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F6E1120077 for <>; Fri, 20 Sep 2019 14:17:17 -0700 (PDT)
Received: by with SMTP id w195so5605965vsw.11 for <>; Fri, 20 Sep 2019 14:17:17 -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; bh=iY0ahH05WtbR7XIDZ9upuhIlG8x7kaMxUDMdMR7jDrU=; b=Vk6FFKuM7ag90+lrV9x2astnXjGcTTMJ0d7rRFGa2hOmlLk4XFLYdvYnbF25zcp0kT 9xJ4iD6Tm4TkWKvi7eZCwPpsOicPXUpAb4pb1IthP7fU4P4lhTUgXdaoLjPpzn0jQsWw 4sYzgzKrsIYb4w3gKbw+hOvlB/VrkkEom8R4h2xHmLcmQZsJqHM86HrCUpaauaWeOpCj p3ItIc9bagTgp3eSAT3t8V93ZROFaU7gKcAQQ3vJVtMOz/Kj8h41LuIbd7rbo6LFWGAF Elnb7IiUe0a9kghrQewjMPlqYo8YP9YmcSXr/hkUGThaEhsv94PL3wNBNRvO/itt+8AW V/ug==
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; bh=iY0ahH05WtbR7XIDZ9upuhIlG8x7kaMxUDMdMR7jDrU=; b=SV2Ortv7ycRibz+xq83FyTx81BMngexb7l2o+4QNKOYpD7UmetwamsoArdaxQ/p7H1 Ij3y6+Dhx6vh+5yCvfadwlGnxeXildSkVmFbhAILMvH8nyWDd/TKsP890+anZbBmixmr qw3eh2aEFF82ExnkiequUJa2JrCBUa98UVO/2UpdbWWjIruCtymCqkq6U0v0B1iMDxWR bWaMCbSwpMJb1BSqdLU5uTecuBXF8UB6l7Rml4xp8jjsIXMPX6QXXPjuXaX5Yc2o8fRy CLuepLmHuFy1DsxUmJUAlGlfct1OvfsXSC5Q0zcml5JV5/plwBol/JkI+fd7jv5r9phq z39w==
X-Gm-Message-State: APjAAAXvFVr06fR2+q6LMFo6WYwl/9aC2xfplVVzjF+Us/BxpAPYy1yR D+lOt4tVXYEpxr4D6EXDNhhwe0HjQOM0KCB0FZJmcK5vUXA=
X-Google-Smtp-Source: APXvYqwNPHKLbTDvlOu/+mYXIDdJ+ktc5n0KOTTgDYcr1W4AH0pRGaN2NX5Y0MPWfNxtablaqBEixQdWb7pQt6vXAHU=
X-Received: by 2002:a67:f9cf:: with SMTP id c15mr3989937vsq.240.1569014235560; Fri, 20 Sep 2019 14:17:15 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Puneet Sood <>
Date: Fri, 20 Sep 2019 17:17:03 -0400
Message-ID: <>
To: 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: Fri, 20 Sep 2019 21:17:20 -0000

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.

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.

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."

2. Extended Error EDNS0 option format
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?

This is unlikely for failures but could happen when DNSSEC validation
could not be performed due to unsupported digest type.

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".

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.


On Thu, Sep 12, 2019 at 9:52 AM Tim Wicinski <> wrote:
> All
> We had such great comments the first time we did a Working Group
> Last Call for draft-ietf-dnsop-extended-error, that the chairs decided
> a second one would be even better.
> Before we start, a few comments:
> - Viktor's comments from 11 September will be rolled into the WGLC
>   comments, which means I'll be tracking them with the authors.
> - The chairs are not doing to add more codes to the IANA registry
>   in the document.  However, the process is laid out in section 5.2,
>   with three different ranges (Expert Review; First Come, First Serve;
>   and Experimental).
> - We're pretty sure all comments have been addressed one way or another,
>   but we still may have missed some.  Please speak up if that is the case.
> This starts a Working Group Last Call for draft-ietf-dnsop-extended-error
> Current versions of the draft is available here:
> The Current Intended Status of this document is: Standards Track
> Please review the draft and offer relevant comments.
> If this does not seem appropriate please speak out.
> If someone feels the document is *not* ready for publication, please speak out with your reasons.
> This starts a two week Working Group Last Call process, and ends on:  26 September 2019.
> thanks
> tim
> _______________________________________________
> DNSOP mailing list