> 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

Reply via email to