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

Eric Orth <> Fri, 24 April 2020 19:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 443663A085B for <>; Fri, 24 Apr 2020 12:15:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Status: No, score=-17.599 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, HTML_MESSAGE=0.001, 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 5-r-yhGtlGP4 for <>; Fri, 24 Apr 2020 12:15:41 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 400833A0860 for <>; Fri, 24 Apr 2020 12:15:41 -0700 (PDT)
Received: by with SMTP id v4so10702927wme.1 for <>; Fri, 24 Apr 2020 12:15:40 -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=esZBxiDVb1CxzZHsXcAwZhhxtfYfxpAs29SVuRusIEk=; b=CsuCESwMSXalcTKDGyVOFQoWXVhDkkMXHletkIhNkFJkaQ+ZmMD2+HnctSw1nhrVjR mD/HGmoXZtRsrJogBbZIDt+8zdlJJv48XDEJ62NSwBJ8Ecaf/RfEhFEoFTc1prsU9BhP Je8rZ4ZEffOLO/vu0C0mh0gaI6Poqug6UHKv6rcxm/8UFEGz+zQ55mmMIyYraI2x+3xl RYnIqrvRpln39swIdNTayvZgb2uh0MjKhGyXiuC4/bbtT0KGO0oxDuM8MCQDW7sMLJD3 OHH7TblyxquacnZyZw+sexA451caEIJeWc6V/ghKJow/nDVHkZv4DTrhQh6g+ubClk5y dEWQ==
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=esZBxiDVb1CxzZHsXcAwZhhxtfYfxpAs29SVuRusIEk=; b=obbULmn+IClgK97s/F3Bhh3HXHmJpXEvfCU9QARkm6aHP4B1cOnxX8LPhnWE1fYABV Od/usJx0K1ie90LE3MgnVsZRZYQBa/APz8FvLwBxgFM9FatXOxEoFlapg1nbys80Rf2V QL+F5p9/q/fh2vNKB/OiqRb7/M3b27arnXV/9SCyd8mLk5gQWc5PjKgnf5gveGqy9qAw cpn2CiNRrZFrSV1djKeQpcgZpHs1CTSN7moSunvBA5ARHFifnqrwUFg9h/BkvjLHvJ6h uJ00VLPEeN7re5IAzT7mX3//Xlwe12BVMz92NR7YbFh6OSpHg53bire8lFTbALI+FOf+ RFfw==
X-Gm-Message-State: AGi0PuYp7/2LQR+tC8RlId+rWR0Iz0i4NKeF9kgiHAhF/tOxZRbylqkO QWSG4trRc99LhtWjxq7QTEhmJYlRXvKtzxKjPQPTfQauPAI=
X-Google-Smtp-Source: APiQypIC9GogBQ75OFsnDjWMMt21pUnkLmX86TZTmoIe85IfgdTXi6qRbjJxKdSQFV/9FMAVpIuzTXrWCUh9qa8oQtk=
X-Received: by 2002:a05:600c:2c47:: with SMTP id r7mr11593794wmg.50.1587755738825; Fri, 24 Apr 2020 12:15:38 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Eric Orth <>
Date: Fri, 24 Apr 2020 15:15:27 -0400
Message-ID: <>
To: dnsop <>
Content-Type: multipart/alternative; boundary="000000000000cdef9805a40e30dc"
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-15.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: Fri, 24 Apr 2020 19:15:43 -0000

Some comments...

Section 3:

"Because long EXTRA-TEXT fields may trigger truncation, which is
undesirable given the supplemental nature of EDE.  Implementers and
operators creating EDE options SHOULD avoid lengthy EXTRA-TEXT contents."

Addition of "because" has created a sentence fragment.  Was the intent to
combine these two sentences with a comma?

Section 6:

"As such, EDE content should be treated only as diagnostic information and
MUST NOT alter DNS protocol processing."

(Sorry for not getting back and responding further on this subject in the
previous thread.)

I still object to the ambiguousness of "alter DNS protocol processing"
within a MUST NOT imperative.  Given that the context here is the security
section and a paragraph on EDE generally being untrusted, how about the
statement be scoped down to "alter DNS protocol processing in ways to place
trust in the authenticity of the EDE" or something like that? And maybe,
since the EDE might be trustworthy in some special cases, eg DoH directly
to a special-purpose known-trustworthy resolver, that MUST NOT should be
toned down to SHOULD NOT?

On Fri, Apr 24, 2020 at 2:23 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
>         Title           : Extended DNS Errors
>         Authors         : Warren Kumari
>                           Evan Hunt
>                           Roy Arends
>                           Wes Hardaker
>                           David C Lawrence
>         Filename        : draft-ietf-dnsop-extended-error-15.txt
>         Pages           : 14
>         Date            : 2020-04-24
> 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