[dane] Please help to remediate broken DNSSEC hosting

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 20 November 2014 06:29 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08BC61A0074 for <dane@ietfa.amsl.com>; Wed, 19 Nov 2014 22:29:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.199
X-Spam-Level: *
X-Spam-Status: No, score=1.199 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_62=0.6, J_CHICKENPOX_72=0.6] autolearn=no
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 kbsXh1v0WXKx for <dane@ietfa.amsl.com>; Wed, 19 Nov 2014 22:29: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 CD4D21A0071 for <dane@ietf.org>; Wed, 19 Nov 2014 22:29:44 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1F9F528304A; Thu, 20 Nov 2014 06:29:42 +0000 (UTC)
Date: Thu, 20 Nov 2014 06:29:42 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20141120062942.GL13179@mournblade.imrryr.org>
References: <20141027225310.29285.24437.idtracker@ietfa.amsl.com> <F0C0FC32-FAA7-4D07-A230-59A538754BCD@isoc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <F0C0FC32-FAA7-4D07-A230-59A538754BCD@isoc.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/zKYG1uOyQD3YxG1Woa1VFguRTzQ
Subject: [dane] Please help to remediate broken DNSSEC hosting
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Nov 2014 06:29:47 -0000

On Mon, Oct 27, 2014 at 10:55:31PM +0000, Dan York wrote:

> Feedback is very definitely welcome... I'm not intending anything
> with this document other than using it as a catalyst for discussions.

Dan, here's something you may be able to help with.

A number of large DNS hosting providers have enabled DNSSEC support,
but are using nameserver software that is not compatible with the
specification with respect to authenticated denial of existence.

In particular, given a zone containing the RRsets below

    *.example.com.	IN A|CNAME|... RDATA
    example.com.	IN MX 0 mail.example.com.
    mail.example.com.	IN A 192.0.2.1

A query for the non-existent "_25._tcp.mail.example.com" is thrown
off by the wildcard record, which has other data, but has no TLSA
RRs, and returns "NODATA" rather than "NXDOMAIN".  So TLSA queries
for such hosted domains SERVFAIL, and mail delivery to these domains
breaks from DANE-enabled MTAs.

    DNS provider     Example domain
    --------------------------------
    forpsi.cz        gigacomputer.cz
    forpsi.cz        websurf.cz
    --------------------------------
    hosting2go.nl    flashpatterns.nl
    hosting2go.nl    informatieplatform.nl
    --------------------------------
    hostnet.nl       bergsalaenigma.nl
    hostnet.nl       brandsupply.nl
    hostnet.nl       expert.nl
    hostnet.nl       foodness.nl
    hostnet.nl       ikkijkonline.nl
    hostnet.nl       leestrainer.nl
    hostnet.nl       studeersnel.nl
    --------------------------------
    transip.nl       aanbodpagina.nl
    transip.nl       androidworld.nl
    transip.nl       bitonic.nl
    transip.nl       codingunit.com
    transip.nl       dresscode.nl
    transip.nl       fonq.nl
    transip.nl       gamesync.nl
    transip.nl       headliner.nl
    transip.nl       icheckmovies.com
    transip.nl       kinderspiele.de
    transip.nl       mediumchat.nl
    transip.nl       notprovided.eu
    transip.nl       performance.nl
    transip.nl       redskillz.nl
    transip.nl       refdag.nl
    transip.nl       seoshop.nl
    transip.nl       trendstats.nl
    transip.nl       webshopapp.com
    transip.nl       webwinkelsoftware.nl
    transip.nl       wrts.nl
    transip.nl       zipzoo.nl
    --------------------------------

For example:

    zipzoo.nl. IN MX 10 mail.zipzoo.nl.
    mail.zipzoo.nl. IN A 95.170.70.251
    mail.zipzoo.nl. IN AAAA 2a01:7c8:eb:0:95:170:70:251
    ;; _25._tcp.mail.zipzoo.nl IN TLSA ?: SERVFAIL

The presence of such broken domains can deter deployment.  Can the
"Deploy360" effort coordinate remediation?  Such hosting sites must
do one of the below to avoid breaking DANE TLSA (at least for SMTP):

  * Deploy a non-broken nameserver.

  * Create kludgey defensive records that make the NODATA response
    correct.

    _25._tcp.mail.zipzoo.nl IN TXT "No TLSA RRs here"

  * Remove the zone's wildcard RRs.

  * Work with the domain owner to remove the DS records for
    the zone making it "insecure".

I don't have the cycles to interface with each hosting provider
and domain owner myself.  We to get the message out to DNS hosting
providers that their software needs to be a robust DNSSEC
implementation, not an ad-hoc patch-set.  At least in the case
of forpsi.cz, I know they're using djbdns, which does not have
fully functional DNSSEC support.

On a related note, some nameservers are failing to provide proof
of the non-existence of a "*._tcp" wildcard, along with the NXDOMAIN
reply for "_25._tcp".

  fuhrt.de.               IN      NS      ns2.remotedienst.de.
  fuhrt.de.               IN      NS      ns1.remotedienst.de.
  fuhrt.de.               IN      MX      10 fuhrt.de.
  ;; _25._tcp.fuhrt.de    IN      TLSA    ?: SERVFAIL

On the other hand for other domains, some sort of firewall or
nameserver bug causes "TLSA" queries to often be simply dropped,
while "A" queries for the same node return NXDOMAIN:

  disa.mil
  fbi.gov
  nic.mil

So I'm running into a non-trivial fraction of signed domains for
which DNSSEC is not working right, and DANE will run into interop
problems.  Can you do anything to help.  My basic plea is:

      * Do it right

but failing that:

      * Don't do it at all.

Neither DNSSEC nor DANE should be fashion statements about how
"cool" a domain is.  These should only be deployed when thoroughly
tested and the ongoing operational responsibilities are under
control.

Finally, while "dnsviz.net" provides the most detailed information
I've found at any testing site, its visual nature and the requirement
to "mouse-over" things to get the key details is often a distraction,
while due to space constraints, the text is often terse and difficult
to understand.

I'm looking for better tools, that non-cryptically explain what is
wrong a query response fails to validate.  A command-line tool I
can run locally would be great, the web version can be for reports
to remote admins so they can use the same tool to check that they've
fixed the problem without needing to install anything.

-- 
	Viktor.