Re: [DNSOP] Asking TLD's to perform checks.

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 11 November 2015 06:47 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3972C1B304A for <dnsop@ietfa.amsl.com>; Tue, 10 Nov 2015 22:47:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJMpVEmh_Na4 for <dnsop@ietfa.amsl.com>; Tue, 10 Nov 2015 22:47:45 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DF051B30B8 for <dnsop@ietf.org>; Tue, 10 Nov 2015 22:47:45 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 22EC22843A5; Wed, 11 Nov 2015 06:47:44 +0000 (UTC)
Date: Wed, 11 Nov 2015 06:47:44 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop@ietf.org
Message-ID: <20151111064744.GW18315@mournblade.imrryr.org>
References: <20151105235402.39FFC3BF2F29@rock.dv.isc.org> <20151110152511.6f1a1c20@pallas.home.time-travellers.org> <20151110204330.C47C63C7D699@rock.dv.isc.org> <7B4B7DEA-C705-437E-8BC1-64D96D55014E@vpnc.org> <0F2DD78A-69C4-49DA-936F-C32D0FC97CC2@rfc1035.com> <5373DDAB-1ED2-489B-AB62-BA7CF6D3DB48@frobbit.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <5373DDAB-1ED2-489B-AB62-BA7CF6D3DB48@frobbit.se>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/K4i_P647QC2lnx9gzkzbvZqqyys>
Subject: Re: [DNSOP] Asking TLD's to perform checks.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dnsop@ietf.org
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Nov 2015 06:47:47 -0000

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.