On Wed, May 6, 2020 at 4:49 AM Stephane Bortzmeyer <bortzme...@nic.fr>
wrote:
> 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 also support adoption and will review/contribute etc.
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.
>
Yup.
> 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 :-{
>
Yes, unfortunately I concur. My experience recently deploying DNSSEC
for a large organization made it clear to me that even recent versions of
mature DNS implementations often have a variety of operationally
impacting DNSSEC bugs.
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"?
>
RFC 6781 Section 4.4.2 (Signature Validity Periods) does mention having
a reasonable signature inception offset, but recommends no value. It does
not mention a signature expiration skew. It would be good to treat this
subject in the document. Personally, I would prefer a fixed value (~ 5 to
10 minutes) rather than a percentage. Otherwise, the validator may be using
a possibly unacceptably small or large skew values depending on the validity
interval.
> 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.)
>
As the spec is currently written, yes, the DNSKEY RRset will give this
information.
Shumon
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
