Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-16.txt

Puneet Sood <> Thu, 14 May 2020 05:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4CD803A0B8A for <>; Wed, 13 May 2020 22:48:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.6
X-Spam-Status: No, score=-17.6 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, 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 OCX4DcmYBszZ for <>; Wed, 13 May 2020 22:48:54 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::932]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 987953A0B88 for <>; Wed, 13 May 2020 22:48:54 -0700 (PDT)
Received: by with SMTP id i5so719596uaq.1 for <>; Wed, 13 May 2020 22:48:54 -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=o0scWCBdxJg0fMtrYxXcZBGaPPP2pmcOD7wX8bydu5s=; b=XmA+MsN0JsY6PE9obkI/Dn+X4tv4nRMRGor/82QdzVbB+slD7JCIw4n7YYfcqV7x+2 W1ktfNyxiNxAyQfyCvN5VAuuP10iD5iSKzLbex4A9NwEC1XgRu5G/DbKwc4+LHXYLrtU gn1991FnBylWRMZF+WO6//DiN0eWH8+97bu5ec82pWFdBzyW8H1E1NDzoO3dfA5GInWr 0wsD1PHqHELZIcSP/GESPaLhUum3YtcOlRSrKE4ircXg+ZztWvTPckz8jt4LGb8QxDcS Vm7bOyjsO0tdNbCg4dTZh/kM0Yt/keShnJvXg7B65HOiGXhMLXh9qWzodagrAUeAmDSN IwuA==
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=o0scWCBdxJg0fMtrYxXcZBGaPPP2pmcOD7wX8bydu5s=; b=Yrdis3ubrSUlKtnHAvVG1irZjJTB1gTm8+K3gsCRAmwQP2vxUw9ps6O+kiPzMH4Q/c cFYgDnzFe61rbs0iWc1KBA0B9WNulpceG841Ciz2o8Ge/XWWjaF1mMvgxyDM+fO1ZjgL aLZdvFGDKKMEMlRnM7kO6Kk44OxDA3GjfdAvDTyA6xv7NYQowuAgnZ6D+S69zIcFkHpL LKisWnUeR6+7RfBNXUhRpiLajytgev5b7nz0UaRhPpnKHkzG4CCgJdpDjRrrJ6bGK+Oa ZRRKb9K7O0CqR8kbVXc8R7FKufHqNQKwWxD1oGrvs09cExocUdUgy6nO5CH9Xao7fNVD P8rA==
X-Gm-Message-State: AOAM530ivmEb6GIqIyAshC7Yah9L0ZBcFWnlHGhWvOsmxeXKtfMaN5JE sJe3aQ9lMCrxutXY9VL5kFZNhAgsBMe9TyGkiUAEfyFvNvc=
X-Google-Smtp-Source: ABdhPJxlOZTOmPkwPPe8ipenbAVYF4fmJGahf9BGclrBUyrJyE3IIwffMYmlMWbOQ4DJMyRJe5ZKzr7ue8qfB99Kwuo=
X-Received: by 2002:ab0:2a8:: with SMTP id 37mr2590934uah.23.1589435332413; Wed, 13 May 2020 22:48:52 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Puneet Sood <>
Date: Thu, 14 May 2020 01:48:39 -0400
Message-ID: <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-16.txt
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: Thu, 14 May 2020 05:48:57 -0000

Google Public DNS is planning to implement this draft in responses
from us (recursive resolver) to clients.

*** Question: When can we expect to have an EDNS option code assigned
for the EDE option?

*** Request for clarification on Section 3. Extended DNS Error Processing
The text in this section (and in the introduction) implies that a
response with a NOERROR RCODE may contain an EDE option.
"Receivers MUST be able to accept EDE codes and EXTRA-TEXT in
 all messages, including those with a NOERROR RCODE, but need not act
 on them"

Scenario: Response has a NOERROR RCODE and contains some response RRs.
If the client sent an EDE option and the server supports EDE, is the
expectation that the server should always include the EDE option?

If the server includes an EDE option in the response, what is the
right EDE code to use? EDE code 0 [other] seems the closest but it
still implies an error. Also the description for it suggests including
EXTRA-TEXT which would not be useful.

If the server does not include an EDE option in the response, the
response looks A-OK to the client. However if the client is attempting
to detect EDE option support on the server it might incorrectly assume
the server does not support EDE.

To simplify the NOERROR scenario, can we have a no error EDE code
similar to the NOERROR RCODE? With this a server can include an EDE
option in all responses to queries containing an EDE option.


On Tue, May 5, 2020 at 4:52 PM <> wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
>         Title           : Extended DNS Errors
>         Authors         : Warren Kumari
>                           Evan Hunt
>                           Roy Arends
>                           Wes Hardaker
>                           David C Lawrence
>         Filename        : draft-ietf-dnsop-extended-error-16.txt
>         Pages           : 15
>         Date            : 2020-05-05
> Abstract:
>    This document defines an extensible method to return additional
>    information about the cause of DNS errors.  Though created primarily
>    to extend SERVFAIL to provide additional information about the cause
>    of DNS and DNSSEC failures, the Extended DNS Errors option defined in
>    this document allows all response types to contain extended error
>    information.  Extended DNS Error information does not change the
>    processing of RCODEs.
> The IETF datatracker status page for this draft is:
> There are also htmlized versions available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> DNSOP mailing list