Hi Jacques, Thanks you for the feedbacks. As suggested by Stephane, the document needs to emphasize on the communication between the client and the resolver. I open the following issue and will address this in the next version. https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/2
Yours, Daniel On Wed, May 6, 2020 at 2:16 PM Jacques Latour <jacques.lat...@cira.ca> wrote: > 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 > -- Daniel Migault Ericsson
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop