IETF Logo Mail Archive

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

Mark Andrews <marka@isc.org> Thu, 04 September 2014 21:00 UTC

Return-Path: <marka@isc.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 C9F891A0184 for <dane@ietfa.amsl.com>; Thu, 4 Sep 2014 14:00:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.331
X-Spam-Level: *
X-Spam-Status: No, score=1.331 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_22=0.6, J_CHICKENPOX_62=0.6, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] 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 NtBeco0hIIPx for <dane@ietfa.amsl.com>; Thu, 4 Sep 2014 14:00:23 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C7291A0115 for <dane@ietf.org>; Thu, 4 Sep 2014 14:00:23 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id BF6451FCBA3 for <dane@ietf.org>; Thu, 4 Sep 2014 21:00:18 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 9DCD5160068 for <dane@ietf.org>; Thu, 4 Sep 2014 21:03:00 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 3556F160052 for <dane@ietf.org>; Thu, 4 Sep 2014 21:03:00 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 09E4D1E6A231 for <dane@ietf.org>; Fri, 5 Sep 2014 07:00:17 +1000 (EST)
To: dane@ietf.org
From: Mark Andrews <marka@isc.org>
References: <20140904202137.GD26920@mournblade.imrryr.org>
In-reply-to: Your message of "Thu, 04 Sep 2014 20:21:37 +0000." <20140904202137.GD26920@mournblade.imrryr.org>
Date: Fri, 05 Sep 2014 07:00:16 +1000
Message-Id: <20140904210017.09E4D1E6A231@rock.dv.isc.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/xTvPgTAbonk4BdgVhd1QVhapRsk
Subject: Re: [dane] DNSSEC debug advice (TLSA lookup problem).
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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:00:26 -0000

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

Then read how DNSSEC works.  No. It doesn't just depend on the
signature on the wildcard CNAME.  That just proves the wildcard
CNAME record itself was not tampered with.  You also need to look
at the NSEC/NSEC3 records to see if a CNAME match is valid or not.

mail2.clarion-hotels.cz. 1788	IN	NSEC	clarion-hotels.cz. A RRSIG NSEC

_tcp.clarion-hotels.cz. falls between mail2.clarion-hotels.cz and
clarion-hotels.cz and it proves that there are names with records
in that range once you verify its signature.

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.

The following response has everything required to prove that there
isn't a TLSA record for _25._tcp.mail2.clarion-hotels.cz.  Firstly
it has a CNAME which can be proved is generated from *.clarion-hotels.cz.
Next it has a NSEC which says the wildcard response is valid.  Next
there is a NSEC which says that there isn't a TLSA record at the
target of the CNAME which only has these records: A NS SOA MX RRSIG
NSEC DNSKEY.  The SOA record says for how long to cache the negative
response.

; <<>> DiG 9.11.0pre-alpha <<>> _25._tcp.mail2.clarion-hotels.cz tlsa +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52644
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;_25._tcp.mail2.clarion-hotels.cz. IN	TLSA

;; ANSWER SECTION:
_25._tcp.mail2.clarion-hotels.cz. 1773 IN CNAME	clarion-hotels.cz.
_25._tcp.mail2.clarion-hotels.cz. 1773 IN RRSIG	CNAME 5 2 1800 20140924121306 20140825121306 13077 clarion-hotels.cz. M8OQ5fcnOYPX2XXvV9Cgefkjv2AHYFLAMeDfUpBuSk1PBFG6s/4tMSLb C/0r72TOjZupOHe5vizyzamAcE6m7dA4tlXGlWkTapf95lKFRokqjQow eRESgmZSS/b43jgxLv/+FRsu3rYnz77j3cC413qBn0PDDKLbepk0YEZC yTk=

;; AUTHORITY SECTION:
mail2.clarion-hotels.cz. 1773	IN	NSEC	clarion-hotels.cz. A RRSIG NSEC
mail2.clarion-hotels.cz. 1773	IN	RRSIG	NSEC 5 3 3600 20140924121306 20140825121306 13077 clarion-hotels.cz. WlUUsb1EqhP5mUfJ5DXpxvVs7Tw4h5802WCwXy4B2NByTbj3SfurhbV7 HBxPFA/I5OR4VkbWsFr7LlOpb93xRmEXt98afdrzzrKIgMIoNHu4oHDe ykeuV/7epjuHOxpZUKtfhe48ktKZ0NRievAyCUxiJA8evpgifR7AKKqS yGA=
clarion-hotels.cz.	3574	IN	SOA	ns.forpsi.net. admin.forpsi.com. 2014082501 3600 1800 2592000 3600
clarion-hotels.cz.	3574	IN	RRSIG	SOA 5 2 3600 20140924121306 20140825121306 13077 clarion-hotels.cz. F5DurWWNlg9zQrvFMQrdNNjH58Zv/TTVBQSOtslMYlwXWp3ZcJGCC1Ra veDuerwFv5dQUsBQIJpQc5eZmyXXH8YA5rOLBK1x19ej0hl1T3yi3pG6 4SJFCrzSIIFVKzX7nKDtfnFK/Zq3X6db7oh9I+gpNnyojuDCccuQNwov kQw=
clarion-hotels.cz.	3574	IN	RRSIG	NSEC 5 2 3600 20140924121306 20140825121306 13077 clarion-hotels.cz. OOeXzp0449w2dXf6zdvnidH69d27+9kPH6fJP9CK+coXuMiZ7WwheIn8 qZrhqYPu9xrnpgmYYkOeuaWDq2b+7rxKzzJTw/0hAjjO8vKRMr2sPyNi CpM2btBTM2FrKZvFJZegMYafo37QH05cg47hXAjEiyEYCMlJfNmMx+AN le8=
clarion-hotels.cz.	3574	IN	NSEC	*.clarion-hotels.cz. A NS SOA MX RRSIG NSEC DNSKEY

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Sep 05 06:45:10 EST 2014
;; MSG SIZE  rcvd: 929

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

Mark


In message <20140904202137.GD26920@mournblade.imrryr.org>, Viktor Dukhovni writ
es:
> Postfix with DANE enabled is unable to deliver mail to mailboxes
> in the "clarion-hotels.cz" domain (validating recursive resolvers
> SERVFAIL TLSA lookups).  The domain is DNSSEC signed:
> 
>     $ dig +ad +noall +comment +ans -t mx clarion-hotels.cz
>     ;; Got answer:
>     ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25470
>     ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
> 
>     ;; ANSWER SECTION:
>     clarion-hotels.cz.      1799    IN      MX      10 mail.clarion-hotels.cz
> .
>     clarion-hotels.cz.      1799    IN      MX      20 mail2.clarion-hotels.c
> z.
> 
> However, it also sports a wildcard CNAME:
> 
>     $ dig +cd +norecur +dnssec +vc -t CNAME "*.clarion-hotels.cz." @ns.forpsi
> .cz
>     ; <<>> DiG 9.8.0rc1 <<>> +cd +norecur +dnssec +vc -t CNAME *.clarion-hote
> ls.cz. @ns.forpsi.cz
>     ;; global options: +cmd
>     ;; Got answer:
>     ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17866
>     ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 8
> 
>     ;; OPT PSEUDOSECTION:
>     ; EDNS: version: 0, flags: do; udp: 4096
>     ;; QUESTION SECTION:
>     ;*.clarion-hotels.cz.		IN	CNAME
> 
>     ;; ANSWER SECTION:
>     *.clarion-hotels.cz.	1800	IN	CNAME	clarion-hotels.cz.
>     *.clarion-hotels.cz.	1800	IN	RRSIG	CNAME 5 2 1800 20140924
> 121306 20140825121306 13077 clarion-hotels.cz. M8OQ5fcnOYPX2XXvV9Cgefkjv2AHYF
> LAMeDfUpBuSk1PBFG6s/4tMSLb C/0r72TOjZupOHe5vizyzamAcE6m7dA4tlXGlWkTapf95lKFRo
> kqjQow eRESgmZSS/b43jgxLv/+FRsu3rYnz77j3cC413qBn0PDDKLbepk0YEZC yTk=
> 
>     ;; AUTHORITY SECTION:
>     clarion-hotels.cz.	3600	IN	NS	ns.forpsi.net.
>     clarion-hotels.cz.	3600	IN	NS	ns.forpsi.it.
>     clarion-hotels.cz.	3600	IN	NS	ns.forpsi.cz.
>     clarion-hotels.cz.	3600	IN	RRSIG	NS 5 2 3600 20140924121
> 306 20140825121306 13077 clarion-hotels.cz. E+Cj1pVvA9v/VP0b2AaOZpENNYiHScIVb
> Xt+h5bpkkl6/iivoTxtORS3 xFCM+mcqkmgQf3xxo9eB0AwbKdf1Mjk4MB4GMn0m2XicWmdRPzHld
> 57Y qr3vorVvOx1OKigLz3LHhYNzp4nC4qIZ1xqhTstgovnlr8I8QB6fhhnu wB4=
>     *.clarion-hotels.cz.	3600	IN	NSEC	mail.clarion-hotels.cz.
>  CNAME RRSIG NSEC
>     *.clarion-hotels.cz.	3600	IN	RRSIG	NSEC 5 2 3600 201409241
> 21306 20140825121306 13077 clarion-hotels.cz. jlZzNSRlMVDZ2YFPwJJLy7ba37h4w35
> +C3ge7iikVx03zIQWiBweU3hJ agqn/eCW8LnKGoDBvTUakvEenPnf9P4PUdOCL3/2trHLyLMv4NC
> afLaT n3d8OSbj6VWCKR1LWNSIcp3es3FbAsdWJtmcXe4oAKSP4i2dBmSEPq/F nS8=
> 
>     ;; ADDITIONAL SECTION:
>     ns.forpsi.net.		1800	IN	A	81.2.194.130
>     ns.forpsi.net.		1800	IN	AAAA	2001:15e8:101:1::c282
>     ns.forpsi.it.		1800	IN	A	62.149.230.87
>     ns.forpsi.cz.		1800	IN	A	81.2.209.185
>     ns.forpsi.cz.		1800	IN	RRSIG	A 5 3 1800 201410041008
> 06 20140904100806 27135 forpsi.cz. Nzo4Ma5iB8QFY6IERC3KLLRPkxsSQgBJgFMQHLl8AG
> uhaNwEeDLUaYz/ ZPjfiH2Rqchc5VV+nWV63gYhVGa4UB2fFLoFFn3L8Y6uTcBe3c7m3AaP ltUcr
> I2Wi7lR6Pf8DkncvtLLaumkRQ6FNkpYjyC/jkbVOMyP1r87TYXZ L78=
>     ns.forpsi.cz.		1800	IN	AAAA	2001:15e8:201:1::d1b9
>     ns.forpsi.cz.		1800	IN	RRSIG	AAAA 5 3 1800 201410041
> 00806 20140904100806 27135 forpsi.cz. TF1AWJD3Wcun92QwS1+ZBy29Zi2qIkBWlYqUeFH
> GxyQhSlcSAWEt+oOr aTyqk79M38mH7TkFzrCBof+TAc6nM9JSOjm9RfmFQ0FVyM1cpmDxD79W co
> BeQcGStVofuvdKeuhZG2oiMyBKrbyUFZw1mgI0bupVs1daIy+zzdcQ 43c=
> 
>     ;; Query time: 104 msec
>     ;; SERVER: 2001:15e8:201:1::d1b9#53(2001:15e8:201:1::d1b9)
>     ;; WHEN: Thu Sep  4 19:57:58 2014
>     ;; MSG SIZE  rcvd: 1156
> 
> I think the DNS servers in question don't correctly handle CNAMEs
> and DNSSEC and this impacts TLSA queries for non-existent records
> (SERVFAIL with many validating resolvers).  The response does not
> include the "*.clarion-hotels.cz" RR and RRSIG).  Instead we have,
> just the requested query name with an RRSIGS as below:
> 
>     _25._tcp.mail.clarion-hotels.cz. 1800 IN RRSIG	CNAME 5 2 1800 \
> 	20140924121306 20140825121306 13077 clarion-hotels.cz. \
> 	M8OQ5fcnOYPX2XXvV9Cgefkjv2AHYFLAMeDfUpBuSk1PBFG6s/4tMSLb \
> 	C/0r72TOjZupOHe5vizyzamAcE6m7dA4tlXGlWkTapf95lKFRokqjQow \
> 	eRESgmZSS/b43jgxLv/+FRsu3rYnz77j3cC413qBn0PDDKLbepk0YEZC yTk=
> 
>     _25._tcp.mail2.clarion-hotels.cz. 1800 IN RRSIG	CNAME 5 2 1800 \
> 	20140924121306 20140825121306 13077 clarion-hotels.cz. \
> 	M8OQ5fcnOYPX2XXvV9Cgefkjv2AHYFLAMeDfUpBuSk1PBFG6s/4tMSLb \
> 	C/0r72TOjZupOHe5vizyzamAcE6m7dA4tlXGlWkTapf95lKFRokqjQow \
> 	eRESgmZSS/b43jgxLv/+FRsu3rYnz77j3cC413qBn0PDDKLbepk0YEZC yTk=
> 
> The suprising thing is that for two different qnames the RRSIG is
> the same, and in fact the same as for the wildcard qname!  If RRSIGs
> depended only on the RDATA and not on the qname, surely there'd be
> serious integrity issues with DNSSEC.  So I think that the
> authoritative servers for this domain are busted, is that correct?
> 
> More complete server responses below (left out the authority and
> additional sections to avoid needless clutter):
> 
>     $ dig +cd +norecur +dnssec +vc -t tlsa "_25._tcp.mail.clarion-hotels.cz."
>  @ns.forpsi.cz
>     ; <<>> DiG 9.8.0rc1 <<>> +cd +norecur +dnssec +vc -t tlsa _25._tcp.mail.c
> larion-hotels.cz. @ns.forpsi.cz
>     ;; global options: +cmd
>     ;; Got answer:
>     ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33941
>     ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1
> 
>     ;; OPT PSEUDOSECTION:
>     ; EDNS: version: 0, flags: do; udp: 4096
>     ;; QUESTION SECTION:
>     ;_25._tcp.mail.clarion-hotels.cz. IN	TLSA
> 
>     ;; ANSWER SECTION:
>     _25._tcp.mail.clarion-hotels.cz. 1800 IN CNAME	clarion-hotels.cz.
>     _25._tcp.mail.clarion-hotels.cz. 1800 IN RRSIG	CNAME 5 2 1800 20140924
> 121306 20140825121306 13077 clarion-hotels.cz. M8OQ5fcnOYPX2XXvV9Cgefkjv2AHYF
> LAMeDfUpBuSk1PBFG6s/4tMSLb C/0r72TOjZupOHe5vizyzamAcE6m7dA4tlXGlWkTapf95lKFRo
> kqjQow eRESgmZSS/b43jgxLv/+FRsu3rYnz77j3cC413qBn0PDDKLbepk0YEZC yTk=
> 
> 
>     $ dig +cd +norecur +dnssec +vc -t tlsa "_25._tcp.mail2.clarion-hotels.cz.
> " @ns.forpsi.cz
>     ; <<>> DiG 9.8.0rc1 <<>> +cd +norecur +dnssec +vc -t tlsa _25._tcp.mail2.
> clarion-hotels.cz. @ns.forpsi.cz
>     ;; global options: +cmd
>     ;; Got answer:
>     ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44567
>     ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1
> 
>     ;; OPT PSEUDOSECTION:
>     ; EDNS: version: 0, flags: do; udp: 4096
>     ;; QUESTION SECTION:
>     ;_25._tcp.mail2.clarion-hotels.cz. IN	TLSA
> 
>     ;; ANSWER SECTION:
>     _25._tcp.mail2.clarion-hotels.cz. 1800 IN CNAME	clarion-hotels.cz.
>     _25._tcp.mail2.clarion-hotels.cz. 1800 IN RRSIG	CNAME 5 2 1800 20140924
> 121306 20140825121306 13077 clarion-hotels.cz. M8OQ5fcnOYPX2XXvV9Cgefkjv2AHYF
> LAMeDfUpBuSk1PBFG6s/4tMSLb C/0r72TOjZupOHe5vizyzamAcE6m7dA4tlXGlWkTapf95lKFRo
> kqjQow eRESgmZSS/b43jgxLv/+FRsu3rYnz77j3cC413qBn0PDDKLbepk0YEZC yTk=
> 
> -- 
> 	Viktor.
> 
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

v2.31.3 | Report a Bug | By Email | System Status