Re: [dane] DNSSEC debug advice (TLSA lookup problem).

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 04 September 2014 21:37 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 DA4D11A0185 for <dane@ietfa.amsl.com>; Thu, 4 Sep 2014 14:37:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level:
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 3tx5NJkkR4_7 for <dane@ietfa.amsl.com>; Thu, 4 Sep 2014 14:37:33 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F4BF1A00FF for <dane@ietf.org>; Thu, 4 Sep 2014 14:37:33 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 298BB2AB2AC; Thu, 4 Sep 2014 21:37:31 +0000 (UTC)
Date: Thu, 04 Sep 2014 21:37:31 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140904213730.GE26920@mournblade.imrryr.org>
References: <20140904202137.GD26920@mournblade.imrryr.org> <20140904210017.09E4D1E6A231@rock.dv.isc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20140904210017.09E4D1E6A231@rock.dv.isc.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/o-Rhkkk7oAs3qnZ-FikdU6nvIeM
Subject: Re: [dane] DNSSEC debug advice (TLSA lookup problem).
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, 04 Sep 2014 21:37:35 -0000

On Fri, Sep 05, 2014 at 07:00:16AM +1000, Mark Andrews wrote:

> Just go and read how the DNS works first.  This will tell you what
> rules DNSSEC has to prove were met for each answer.

Yes, in fact between posting and reading your answer, I went off
and did some reading.  The problem as I now understand it seems to
be that:

	1.   *.clarion-hotels.cz IN CNAME 	exists.
	2.   mail2.clarion-hotels.cz		exists.
	3.   _tcp.mail2.clarion-hotels.cz	does not exist.

and finally, the nameservers for clarion-hotels.cz incorrectly
apply the wildcard CNAME to a child of an existing sibling node
(mail2).  This is detected as an error by various validating
resolvers.

Is this right?

> The RRSIG for _25._tcp.mail2.clarion-hotels.cz says it was generated
> from a wildcard record which the validator proved by retaining the
> correct number of labels to form the suffix of the wildcard record
> and adding a '*' label.  This gives the name of the record that was
> signed.  The number of labels is also part of the data that is
> hashed to form the RRSIG.

Right, so along with this there needs to be a non-existence proof
for the labels replaced with the wildcard, but there is no such
proof, because "mail2" exists.

> Now can we please stop second guessing whether DNSSEC actually
> works.  It does.

Sorry, I was just surprised by the RRSIG values being the same for
multiple qnames, but did not know about the RRSIG label count field.
So my guess was way off, but it was a guess, and I did ask for
advice from folks who actually know how this works.

So now I need to figure out what manner of broken name servers are:

    ns.forpsi.cz
    ns.forpsi.it
    ns.forpsi.net

-- 
	Viktor.