Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements

Stephane Bortzmeyer <> Wed, 06 May 2020 08:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C74593A0061; Wed, 6 May 2020 01:48:42 -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 xlm-n4i7tDBy; Wed, 6 May 2020 01:48:40 -0700 (PDT)
Received: from ( [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E5FF83A00DB; Wed, 6 May 2020 01:48:39 -0700 (PDT)
Received: from (localhost []) by (Postfix) with SMTP id E962628053E; Wed, 6 May 2020 10:48:36 +0200 (CEST)
Received: by (Postfix, from userid 500) id E284C28066E; Wed, 6 May 2020 10:48:36 +0200 (CEST)
Received: from ( [IPv6:2001:67c:2218:15::11]) by (Postfix) with ESMTP id DA85F28053E; Wed, 6 May 2020 10:48:36 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id D39FD663E080; Wed, 6 May 2020 10:48:36 +0200 (CEST)
Received: by (Postfix, from userid 1000) id C105C3FD5F; Wed, 6 May 2020 10:48:36 +0200 (CEST)
Date: Wed, 06 May 2020 10:48:36 +0200
From: Stephane Bortzmeyer <>
To: Tim Wicinski <>
Cc: dnsop <>, dnsop-chairs <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
X-Operating-System: Debian GNU/Linux 10.3
X-Kernel: Linux 4.19.0-8-amd64 x86_64
X-Charlie: Je suis Charlie
Organization: NIC France
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Bogosity: No, tests=bogofilter, spamicity=0.000883, version=1.2.2
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2019.11.5.63017
Archived-At: <>
Subject: Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements
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: Wed, 06 May 2020 08:48:43 -0000

On Mon, May 04, 2020 at 03:08:20PM -0400,
 Tim Wicinski <> wrote 
 a message of 64 lines which said:

> This starts a Call for Adoption for
> draft-mglt-dnsop-dnssec-validator-requirements

I think it is important to have such a document, because DNSSEC
failures may seriously endanger the deployment of DNSSEC (which is
already too low). The current draft seems a good starting point and I
support its adoption.

I'm willing to review. Let's start immediately with -09:

draft-ietf-dnsop-extended-error (recently approved by the IESG) should
be mentioned, since one of the biggest operational problem with DNSSEC
is the difficulty to understand why a resolver returns a SERVFAIL to

> More often, to date, failed validation is due to operator error and
> not an attempt to forge data.

It can be a bug in software, too. Specially with complicated things
like NSEC3+optout+ENT+dynupdate :-{

The draft apparently do not mention advices on expiration slack (such
as val-sig-skew-min and val-sig-skew-max in Unbound). Is there a
consensus on (I quote Unbound documentation) "The signature inception
and expiration dates are allowed to be off by 10% of the signature

> However, a DNSSEC validator is not able to determine other than by
> trying whether a signature scheme is supported by the authoritative
> server.

This one is unclear. First, the signer is not always an authoritative
server, signature can be done offline. Second, querying the DNSKEY is
enough, no? (Or querying the signatures, but I assume a zone won't
publish a DNSKEY without being able to sign with this algorithm.)

Section 12 "Invalid Reporting Recommendations" is questionable. Since
most DNSSEC validation errors are not attacks, reporting these errors
may overload the DRO with problems she can do nothing
about. Monitoring is a good idea but monitoring what? "Important" (for
the DRO) domains?

Also, the draft has many, it seems, grammar / language
problems. ("This introduces a potentially huge vector for
configuration errors, but due to human intervention as well as
potential misunderstanding of ongoing operations.")