On Wed, Nov 11, 2015 at 07:25:39AM +0100, Patrik Fältström wrote:

> Everything has so far collapsed into collision between tech people not
> agreeing on what is right and wrong. It also collapses into clashes between
> registry policy and the tests made. I.e. just the registration policy is
> setting blocks and constraints on what tests must be made (or can not be
> made). And harmonization of such rules is just impossible (we have seen).

It may not be possible for everyone to agree on a comprehensive
set of 'wrongs' with no omissions, but it should be possible to
get consensus on a core set of 'wrongs' that are not controversial.

For DNSSEC domains (from actual observations), at least some of
the below should be widely seen as mistakes to avoid: 

  * Dropping TLSA (or other "unexpected" RRtype) queries is wrong.
    A simple NODATA or NXDOMAIN is the right way to go.

  * Returning wildcard responses for children of a sibling empty
    non-terminal is wrong.
 
  * Returning NXDOMAIN with proof of NODATA is wrong.

  * Returning NODATA with proof of NXDOMAIN is wrong.

  * Returning incorrect denial of existence NSEC/NSEC3 records for
    nodes that are not immediately below the zone apex is wrong.
    (Essentially failure to establish the proper closest encloser,
     and proof of non-existence of its immediate descendant and
     child wildcard).

  * Returning an incorrect SOA RRSIG with negative replies is wrong.
    Especially when queries for the SOA itself return a correct RRSIG.

  * Returning NSEC/NSEC3 records with no associated RRSIGs is wrong.

  * Having DS records in the parent zone with no matching DNSKEYs
    at the zone apex is wrong.

  * ...

  * Lame delegations are wrong.

  * Setting the NSEC3 opt-out bit for "non-registry" zones is not
    recommended.

I am sure we can flesh out a list.  A good start might the issues
which "dnsviz" flags as "error" or "bogus".  Even some "dnsviz"
warnings are worth highlighting, such as conflict between the
delegation NS records and the zone apex NS records.

-- 
        Viktor.

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to