[DNSOP] Comments on draft-ietf-dnsop-extended-error-08

Paul Hoffman <paul.hoffman@icann.org> Wed, 21 August 2019 00:12 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6C4D1120854 for <dnsop@ietfa.amsl.com>; Tue, 20 Aug 2019 17:12:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id EhB6pvUZ3EKk for <dnsop@ietfa.amsl.com>; Tue, 20 Aug 2019 17:12:39 -0700 (PDT)
Received: from ppa2.lax.icann.org (ppa2.lax.icann.org []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B590712003F for <dnsop@ietf.org>; Tue, 20 Aug 2019 17:12:39 -0700 (PDT)
Received: from PFE112-CA-2.pexch112.icann.org (out.west.pexch112.icann.org []) by ppa2.lax.icann.org ( with ESMTPS id x7L0Cc01021350 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for <dnsop@ietf.org>; Wed, 21 Aug 2019 00:12:38 GMT
Received: from PMBX112-W1-CA-1.pexch112.icann.org ( by PMBX112-W1-CA-2.pexch112.icann.org ( with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 20 Aug 2019 17:12:36 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([]) with mapi id 15.00.1473.005; Tue, 20 Aug 2019 17:12:36 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: IETF DNSOP WG <dnsop@ietf.org>
Thread-Topic: Comments on draft-ietf-dnsop-extended-error-08
Thread-Index: AQHVV7UiLg765ESmzEKUqNyAooOY0A==
Date: Wed, 21 Aug 2019 00:12:35 +0000
Message-ID: <EA557043-34D1-43EA-B750-4A17CFC6BE50@icann.org>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
x-source-routing-agent: Processed
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9C050F2BFD30894A8CF277704E2C3721@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-20_11:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/oDPMjw1HcR_qdct9N0yLBd64dXU>
Subject: [DNSOP] Comments on draft-ietf-dnsop-extended-error-08
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Aug 2019 00:12:42 -0000

Greetings again. The changes here generally help the document, but they also highlight some of the deficiencies. A few comments on the current draft:

- The spec does not say anything about the kinds of responses where it is allowed to send particular extended error codes. For example, if a response has an RCODE of NOERROR, what does it mean for it to also have a EDE? Or if the RCODE is FORMERR, can it have an EDE that relates to DNSSEC validation failure? The exact semantics for the receiver need to be specified.

- In the introduction, it says:
   This document specifies a mechanism to extend (or annotate) DNS
   errors to provide additional information about the cause of the
"extend" and "annotate" have very different meanings. This is the crux of the use of the mechanism, so it needs to be clearer.

- In the introduction, it says:
   These extended error codes are specially useful when received
   by resolvers, to return to stub resolvers or to downstream resolvers.
   Authoritative servers MAY parse and use them, but most error codes
   would make no sense for them.  Authoritative servers may need to
   generate extended error codes though.
This is confusing because many authoritative servers also send queries when they are doing AXFR and so on. Instead, I propose:
   These extended error codes described in this document can be used
   by any system that sends DNS queries. Different codes are useful
   in different circumstances, and thus different systems (stub
   resolvers, recursive resolvers, and authoritative resolvers)
   might receive and use them.

- Sections 3.1 and 3.2 repeat the information at the end of Section 2, and thus should be eliminated. Instead, leave Section 2 as is, and simply include the the first paragraph of Section 3, and then eliminate Section 3 altogether.

- There are many places where the document uses flippant language that could confuse readers who don't understand English idioms. Although they are somewhat humorous, these could lead to confusion and should be removed.

--Paul Hoffman