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

Viktor Dukhovni <> Sat, 07 November 2015 19:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 65C7E1B2E71 for <>; Sat, 7 Nov 2015 11:11:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FVk0en-9b_1Q for <>; Sat, 7 Nov 2015 11:11:07 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E514D1B2E68 for <>; Sat, 7 Nov 2015 11:11:06 -0800 (PST)
Received: by (Postfix, from userid 1034) id 8CA93284DF5; Sat, 7 Nov 2015 19:11:05 +0000 (UTC)
Date: Sat, 07 Nov 2015 19:11:05 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
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: Sat, 07 Nov 2015 19:11:09 -0000

On Fri, Nov 06, 2015 at 10:54:02AM +1100, Mark Andrews wrote:

> 	I keep getting told the IETF can't tell people what to do
> 	but that is *exactly* what we do do when we issue a BCP.
> 	We tell people what best current practice is and ask them
> 	to follow it.
> 	Today we have TLDs that do perform all sorts of checks on
> 	servers they delegate zones to and some do inform the
> 	operators of those zones that they have errors.  Those
> 	checks cover in part tests described in
> 	draft-andrews-dns-no-response-issue.
> 	So do we adopt this or do we continue to lie to ourselves
> 	about what BCP actually do?

If this is about:

then I for one strongly support its adoption.  I've been doing DANE
SMTP adoption surveys for over a year now, and have run into quite
a few nameserver operators with a number of DNSSEC issues.  I've
found especially the SIDN (.nl) registry very helpful in interfacing
with DNS hosting providers to address the reported issues, but have
also had some help from .cz, .se and .gov.  Today I reached out to, they'll likely be helpful too.

It would be great if I did not have to nag each operator or hosting
provider I happened to find, and instead registries would make
periodic efforts to validate the correctness of all delegations.
Recommending this as a best practice seems quite reasonable.

As to what makes a delegation valid, it is not too difficult to
construct a sensible list of tests.  The site seems to
have no trouble testing for a reasonably comphensive set of warnings
and errors.

In addition to all the obvious tests of the consistency of delegation
records with data at the zone apex, no lame delegations, DS records
having matching DNSKEY records, ... Based in part on:

I'd also check for:

    * Not dropping queries for unexpected RRtypes (which are
      misguidedly droppped as a "security feature" by some systems).
      Especially TLSA RRs, which are starting to get used with SMTP.

    * Correct processing of denial of existence in signed zones:

	; Check for valid NXDOMAIN or NODATA (if wildcard applies)
	made-up-label2.made-up-label1.<zone-apex>. IN A ?
	made-up-label2.made-up-label1.<zone-apex>. IN AAAA ?
	made-up-label2.made-up-label1.<zone-apex>. IN TLSA ?

	; Check for valid NXDOMAIN or NODATA (if wildcard applies)
	; if in bailiwick known names exist below the zone apex.
	; Names of MX hosts are often a good source of such names.
	made-up-label2.made-up-label1.known-name.<zone-apex>. IN A ?
	made-up-label2.made-up-label1.known-name.<zone-apex>. IN AAAA ?
	made-up-label2.made-up-label1.known-name.<zone-apex>. IN TLSA ?

For example, returns NSEC RRsets with no RRSIG for multiple
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 24618
    ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
    ; IN TLSA                SOA 2015101800 10800 3600 1209600 3600                RRSIG   SOA 5 2 86400 20160218062849 20151018062849 12273           NSEC A RRSIG NSEC                NSEC A NS SOA MX RRSIG NSEC DNSKEY

I notified them, whether action will be take is not yet clear.