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

Jacques Latour <> Wed, 06 May 2020 18:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F2A4B3A09EF; Wed, 6 May 2020 11:15:31 -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 mrvFcMooIiDR; Wed, 6 May 2020 11:15:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9BB893A09E0; Wed, 6 May 2020 11:15:27 -0700 (PDT)
X-Virus-Scanned: by SpamTitan at
Authentication-Results:; none
Received: from CRP-EX16-02.CORP.CIRA.CA ( by CRP-EX16-02.CORP.CIRA.CA ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1531.3; Wed, 6 May 2020 14:15:22 -0400
Received: from CRP-EX16-02.CORP.CIRA.CA ([fe80::c90:b1ae:52f6:5fca]) by CRP-EX16-02.CORP.CIRA.CA ([fe80::c90:b1ae:52f6:5fca%14]) with mapi id 15.01.1531.010; Wed, 6 May 2020 14:15:22 -0400
From: Jacques Latour <>
To: Stephane Bortzmeyer <>, Tim Wicinski <>
CC: dnsop <>, dnsop-chairs <>
Thread-Topic: [EXT] Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements
Thread-Index: AQHWI4Mt4hKYxGgDuEmEhGolTTycBaibW+zw
Date: Wed, 06 May 2020 18:15:22 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-CA, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [DNSOP] [EXT] Re: 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 18:15:32 -0000

I support the adoption of this document as well, perhaps a bit long but as Stéphane stated with draft-ietf-dnsop-extended-error, it would nice to have a good story on understanding why resolvers return SERVFAIL.
>-----Original Message-----
>From: DNSOP <> On Behalf Of Stephane Bortzmeyer
>Sent: May 6, 2020 4:49 AM
>To: Tim Wicinski <>
>Cc: dnsop <>; dnsop-chairs <>
>Subject: [EXT] Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements
>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.")
>DNSOP mailing list