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 <dnsop-boun...@ietf.org> On Behalf Of Stephane Bortzmeyer
>Sent: May 6, 2020 4:49 AM
>To: Tim Wicinski <tjw.i...@gmail.com>
>Cc: dnsop <dnsop@ietf.org>; dnsop-chairs <dnsop-cha...@ietf.org>
>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 <tjw.i...@gmail.com> 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
>you.
>
>> 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
>lifetime"?
>
>> 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
>DNSOP@ietf.org
>https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
