> On May 15, 2018, at 2:29 PM, John Levine <jo...@taugh.com> wrote: > > I think you will find that attempts to legislate against being stupid > do not generally turn out well. It makes sense to check for mistakes > that might screw up the upper level name server like an invalid > algorithm number, but if they want to shoot themselves in the foot, > there's not much we can do about that. > > There's no way to make a list of every possible stupid thing that > someone might do, so I wouldn't try.
Some of the more subtle, but still very important failure modes are not obvious unless *tested*. It is would be a disservice to the ecosystem to blindly turn on only partly working DNSSEC which is actually broken in important ways. Section 3.4 says: The Registration Entity, upon receiving a signal or detecting through polling that the child desires to have its delegation updated, SHOULD run a series of tests to ensure that updating the parent zone will not create or exacerbate any problems with the child zone. The basic tests SHOULD include: [...] And while we can't enumerate all possible breakage, there are clear mistakes that are comparatively common now, and which would become much more prevalent if enrollment is made easier with no due care to ensure that we're not adding to the problems. * Incomplete NSEC chains that break denial of existence of the TLSA records of any explicit (or implicit zone apex) MX hosts. * SOA signatures that are invalid (typically modified after signing) * RRtype-based query filtering that drops TLSA/CAA/... queries. * ... and a few more ... The above are not made-up hypotheticals, they are actually observed in sufficient numbers to establish a pattern of likely failure modes that need to be tested. I have around ~200 samples that provide strong evidence of the most common failure modes. We can perhaps quibble over which failures might be ignored, but it would be irresponsible and counter-productive to ignore them all. -- -- Viktor. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop