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

Wes Hardaker <> Fri, 27 September 2019 23:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B3D3120072 for <>; Fri, 27 Sep 2019 16:44:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id REcnhgIwo6RQ for <>; Fri, 27 Sep 2019 16:44:18 -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 A539E120071 for <>; Fri, 27 Sep 2019 16:44:18 -0700 (PDT)
Received: from localhost (unknown []) by (Postfix) with ESMTPA id 20B422DD7C; Fri, 27 Sep 2019 16:44:16 -0700 (PDT)
From: Wes Hardaker <>
To: Viktor Dukhovni <>
References: <> <>
Date: Fri, 27 Sep 2019 16:44:15 -0700
In-Reply-To: <> (Viktor Dukhovni's message of "Wed, 11 Sep 2019 02:05:29 -0400")
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-09.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, 27 Sep 2019 23:44:21 -0000

Viktor Dukhovni <> writes:

Thanks Viktor,

Thanks for the comments.  Responses are inline below in my tracking
notes below.

14.1 DONE Viktor Dukhovni

14.1.1 DONE Introduction 3rd paragraph (missing verb, extra period):

  [...] These extended DNS error codes [are?] described in this document
  and can be used by any system that sends DNS queries and receives a
  response containing an EDE option.. [...]

14.1.2 DONE With respect to the much discussed caveat:

  This document does not allow or prohibit any particular extended error
  codes and information be matched with any particular RCODEs.  Some
  combinations of extended error codes and RCODEs may seem nonsensical
  (such as resolver-specific extended error codes in responses from
  authoritative servers), so systems interpreting the extended error
  codes MUST NOT assume that a combination will make sense.  Receivers
  MUST be able to accept EDE codes and EXTRA-TEXT in all messages,
  including even those with a NOERROR RCODE.

  My take is that when the (12 bit EDNS) RCODE and new extended error
  are in apparent conflict, I should treat the RCODE as definitive, and
  ignore the extended error code.  That is, the extended error can
  *refine* but not contradict the status indicated by the RCODE.  If
  that's correct, perhaps it should be stated explicitly.  If not
  correct, then a clarification is perhaps still in order.

  + Response: there seems to be consensus around this and I adopted
    Paul's text to clarify this

14.1.3 DONE Section 2, 3rd bullet:  s/index to/index into/

  The INFO-CODE serves as an index to the "Extended DNS Errors" registry
  Section 4.1.

14.1.4 DONE Section 2, 4th bullet: s/be take/be taken/

  Care should be take not to leak private information that an observer
  would not otherwise have access to, such as account numbers.

14.1.5 NOCHANGE account numbers and privacy

  I find "such as account numbers" a bit of a non sequitur (what account
  numbers?) I'd drop this, or produce a more transparent example.

  + Response: I agree, it's a bit of an unusual statement.  But it was
    suggested by Shane Kerr in the summer and if you want to suggest
    better text for replacing it, I need a real suggestion as deleting
    it would delete his desire to have an example in there (which I
    agree with, FWIW).  Maybe "account name" would be a middle ground?

14.1.6 DONE Section 3.2 (code 2), may warrant more guidance on when this is

  appropriate.  AFAIK, there is nothing wrong with all DNSKEY algorithms
  being unsupported, provided the same holds for the DS RRset.  So,
  while I see a use-case for code 3 (all DS unsupported, perhaps to
  signal why the AD bit is not set, despite the non-empty DS RRset), I
  don't understand when one would use code 2.

  + Vladimír Čunát adds

    I do fail to understand the split codes 1 and 2 for all DS/DNSKEY
    algorithms being unsupported, and it actually makes me wonder how to
    exactly write the resolver code that would set this pair.  For
    validation I need at least one usable DS RR, i.e. one where *both*
    the DS and DNSKEY algorithms are supported.  I believe that's the
    exact condition to be able to extend the trust chain. (and that's
    how I implemented it for Knot Resolver)  It may theoretically even
    happen that there is a supported DS algorithm and a supported DNSKEY
    algorithm but never paired together in the DS RRset - IIRC it's not
    perfectly correct to generate such an RRset but that's probably not
    something a validator should care for.

  + Response: Error 1 (unsupported DNSKEY alg) could be included in any
    message where the DNSKEY algorithm (say 1 RSA/MD5) isn't
    supported. A servfail would be returned with EDE-1 as well.

    For DS unsupported, a similar case occurs when chaining from the
    parent and a DS Digest Type of 1 (MD5) is hit that the validator
    doesn't support.  I *think* the problem is that the text should
    really say "Unsupported DS Digest Type", which I'll go change it to.
    Let me know if that's wrong.

14.1.7 DONE Section 3.6, code 6 (indeterminate answer) needs clarification,

  since there is no single defintion of "indeterminate" in DNSSEC.  In
  particular different definitions are given in RFCs 4034 and 4035 (as
  explained in []).

  My take is that with the root zone signed, the 4033 definition is
  obsolete, and the correct one is 4035.  This should probably be made

  4035 "indeterminate":

  An RRset for which the resolver is not able to determine whether the
  RRset should be signed, as the resolver is not able to obtain the
  necessary DNSSEC RRs.  This can occur when the security-aware resolver
  is not able to contact security-aware name servers for the relevant

  4033 "indeterminate":

  There is no trust anchor that would indicate that a specific portion
  of the tree is secure.

  + Response: good point.  I'll use a reference to 4035.

14.1.8 DONE Section 3.8, the text reads:

  The resolver attempted to perform DNSSEC validation, but a signature
  in the validation chain was expired.

  However, there are recent observations of domain where each RRset was
  accompanied by both expired *and* unexpired RRSIGs.


  So just *an* expired signature is not really a problem provided
  another signature for the same RRset is not expired.  So I think the
  text could more clearly read "but *all* signatures for an RRset in the
  validation chain expired", or some such.

  + Response: good point, changed

  + Vladimír Čunát adds

  Nitpick: *if* we were diving into such details... each RRSIG might
  fail for a different reason, for example.  That's the general problem
  with providing reasons for validation failures: validation is defined
  in the sense that you (may) succeed when at least one of various ways
  succeeds.  A failure could typically be fixed by multiple different
  ways (EDE codes).  Still, I'd hope that in most real-life cases the
  implementations can "correctly" guess what's wrong.

  + Response: That's true, and I think if you had sigs that were both
    "early" and "late" but not "now" you'd return both codes or more
    likely an "other" error code (0) with informational text.

14.1.9 NOCHANGE Section 3.13: the text reads:

  The resolver attempted to perform DNSSEC validation, but the requested
  data was missing and a covering NSEC or NSEC3 was not provided.

  I think that "missing" can be misleading, it is not that the answer is
  "missing" from the response, but rather that the response
  affirmatively denies the existence of the requested RRset.  So perhaps
  "but the response denies the existence of the requested RRset" or
  something similar.

  + I think you're misreading that section (or I'm not following).  The
    point is that the validator *failed* to get a NSEC or NSEC3 that
    proved the name doesn't exist to match the NXDOMAIN.  So the
    validator changed all the way down through keys and then got an
    NXDOMAIN with no NSEC for 'wwww'.

14.1.10 DONE I find the two sections:

  3.16.  Extended DNS Error Code 15 - Blocked 3.17.  Extended DNS Error
  Code 16 - Censored

  somewhat confusing, it seems that the resolver returning the answer is
  reporting second-hand status from an upstream server, but the language
  leaves me unsure.  Perhaps this can be stated more clearly.

  + Response: Those three codes were supplied in a previous comment
    round and they are supposed to indicate policies being applied from
    different sources.  Can you check the new text of them to see if
    they are more understandable now?

Wes Hardaker