Re: [DNSOP] Comments on draft-ietf-dnsop-extended-error version 10

Wes Hardaker <> Mon, 30 September 2019 21:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F8C512016E for <>; Mon, 30 Sep 2019 14:05:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wefOWLPDHD23 for <>; Mon, 30 Sep 2019 14:05:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4AA0B12007C for <>; Mon, 30 Sep 2019 14:05:57 -0700 (PDT)
Received: from localhost (unknown []) by (Postfix) with ESMTPA id 5222A299DD; Mon, 30 Sep 2019 14:05:48 -0700 (PDT)
From: Wes Hardaker <>
To: Mats Dufberg <>
Cc: "dnsop\" <>
References: <>
Date: Mon, 30 Sep 2019 14:05:48 -0700
In-Reply-To: <> (Mats Dufberg's message of "Mon, 30 Sep 2019 12:46:39 +0000")
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [DNSOP] Comments on draft-ietf-dnsop-extended-error version 10
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: Mon, 30 Sep 2019 21:05:59 -0000

Mats Dufberg <> writes:

> Section 1 ends with "Receivers MUST NOT change the processing of
> RCODEs in messages based on extended error codes" but it is not fully
> clear what that statement means in the light of the description in the
> beginning of the same section where the motivation for extended error
> codes is that the resolver cannot know what specific error that is
> behind, e.g., REFUSED and there does not know what the best next step
> is.

See the discussion with Eric about new wording for that sentence.  That
being said, I think your point is valid about misunderstanding the
purpose as well.  So I've added this sentence to the end of the first

      What error messages should be presented to the user or logged
      under these conditions?</t>

Seem ok?

> Both section 3.18 (filtered) and section 3.19 (prohibited) has code 17. In the
> registry table (4.2) it is code 17 and 18, respectively.

Fixed, thanks.

> Both 3.14 (Cached error) and 3.20 (Stale NXDOMAIN answer) reports that the
> RCODE returned was taken from cached. In 3.20 it is described in detail what
> the resolver has done before the answer is returned, whereas in 3.14 there are
> not details at all.
> 3.14 needs more specification of when to use cached SERVFAIL.

Hmm...  What more would I put other than "the resolver is to include
this when it returns a SERVFAIL from the cache?"  I've changed the text

    The resolver is returning the SERVFAIL RCODE from its cache.

Which I think is clearer.

> I think that the last sentence in 3.20 ("This is typically caused [...] result
> of a DoS attack against another network") does not belong to a standard
> document.

I've changed it to this:

          This is may be caused, for example, by problems
          communicating with an authoritative server, possibly as
          result of a DoS attack against another network.

Which removes "typically", which I think you're right is out of place.
I don't think removing the sentence is helpful to the reader, so I'd
rather fix it.

> In 3.22 it would be better to say that the operation or query is not supported
> ("Not supported"). As the text is now it is unclear by whom it is deprecated.

Ok, I'm fine with that.  Changed.

> I suggest that the sentence "This may occur because its most recent
> zone is too old, or has expired, for example" is removed from 3.25
> since there could be multiple reasons and it is not needed to give an
> example in a standard document.

I'm not sure why you think examples aren't useful in standards
documents?  IMHO, they're used all the time (the IMAP RFC is one of my
favorites that is full of example usages).  In the previous example you
brought up above, I agree that we shouldn't be determining commonality
of possibilities.  But I think examples in generally greatly help the
reader determine how to more accurately interpret a specification. 

Wes Hardaker