Re: [dane] [Trans] CT for DNSSEC

Viktor Dukhovni <> Wed, 29 March 2017 15:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E345127599; Wed, 29 Mar 2017 08:18:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3drPfO664MML; Wed, 29 Mar 2017 08:18:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1D73712954A; Wed, 29 Mar 2017 08:11:42 -0700 (PDT)
Received: from vpro.lan ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 5749C7A32F1; Wed, 29 Mar 2017 15:11:41 +0000 (UTC) (envelope-from
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni <>
In-Reply-To: <>
Date: Wed, 29 Mar 2017 11:11:40 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [dane] [Trans] CT for DNSSEC
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Mar 2017 15:18:45 -0000

> On Mar 29, 2017, at 10:33 AM, Wei Chuang <> wrote:
> Why not create an explicit Non-existence of DS (NDS) RR that gets logged along with DS and NS?

This is not needed, the NSEC/NSEC3 RRs already serve that role.

For NSEC records (RFC4034), an unsigned delegation looks like: IN NS IN NSEC NS IN RRSIG NSEC ...

this proves that NS (or other depending on the content of the type
bitmap of the NSEC record) records exist for, but DS
records do not.

With NSEC3 (rfc5155), and the "opt-out" bit the situation can be
more complex because the answer may not establish the existence of  Instead we may get an existence proof for the closest
encloser (ancestor domain) and proof that "" is not signed,
but no proof of its existence.  This means that to avoid spam, a log
might want to independently verify the existence of the insecure
delegation by repeating the query, so as to avoid storing data for
non-existent domains with the insecure NXDOMAIN modified to NOERROR
with made up NS records.