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

Viktor Dukhovni <> Wed, 11 November 2015 09:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0628A1B3427 for <>; Wed, 11 Nov 2015 01:00:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GncZ0YMqKfPR for <>; Wed, 11 Nov 2015 01:00:03 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7C2011A8843 for <>; Wed, 11 Nov 2015 01:00:03 -0800 (PST)
Received: by (Postfix, from userid 1034) id 368302843A5; Wed, 11 Nov 2015 09:00:02 +0000 (UTC)
Date: Wed, 11 Nov 2015 09:00:02 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <>
Subject: Re: [DNSOP] Asking TLD's to perform checks.
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Nov 2015 09:00:05 -0000

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

> > 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.
> Yes and no. I think going for a minimum will be a good goal, but for
> example to have lame delegations must by definition be allowed, as some
> registration policies do require delegation (i.e. NS records). So people
> add NS records in parent zone, but nothing responds there. Until policy
> allows registration without delegation, you will see lame delegations.

My quick and dirty list is likely not "the list".  Mark correctly
points out starting with protocol (rather than content) issues is
a good idea.  Since lame delegations are content, they might be
out of scope.  I think that broken denial of existence is also a
protocol (software quality) issue, rather than zone data content.

This is not to say that no content issues can be in scope, but
likely those would need closer scrutiny.

For example, having DS RRs with no corresponding DNSKEY RRs invites
serious trouble, and does not seem to have a plausible reason (like
lame delegations).  But I'm presently setting any specifics in stone.

Just saying that progressing Mark's draft looks like a good idea
to me.