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

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 4 Sep 2014 20:21:37 +0000

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.cz.

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-hotels.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 20140924121306 20140825121306 13077 clarion-hotels.cz. M8OQ5fcnOYPX2XXvV9Cgefkjv2AHYFLAMeDfUpBuSk1PBFG6s/4tMSLb C/0r72TOjZupOHe5vizyzamAcE6m7dA4tlXGlWkTapf95lKFRokqjQow 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 20140924121306 20140825121306 13077 clarion-hotels.cz. E+Cj1pVvA9v/VP0b2AaOZpENNYiHScIVbXt+h5bpkkl6/iivoTxtORS3 xFCM+mcqkmgQf3xxo9eB0AwbKdf1Mjk4MB4GMn0m2XicWmdRPzHld57Y 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 20140924121306 20140825121306 13077 clarion-hotels.cz. jlZzNSRlMVDZ2YFPwJJLy7ba37h4w35+C3ge7iikVx03zIQWiBweU3hJ agqn/eCW8LnKGoDBvTUakvEenPnf9P4PUdOCL3/2trHLyLMv4NCafLaT 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 20141004100806 20140904100806 27135 forpsi.cz. Nzo4Ma5iB8QFY6IERC3KLLRPkxsSQgBJgFMQHLl8AGuhaNwEeDLUaYz/ ZPjfiH2Rqchc5VV+nWV63gYhVGa4UB2fFLoFFn3L8Y6uTcBe3c7m3AaP ltUcrI2Wi7lR6Pf8DkncvtLLaumkRQ6FNkpYjyC/jkbVOMyP1r87TYXZ L78=
    ns.forpsi.cz.		1800	IN	AAAA	2001:15e8:201:1::d1b9
    ns.forpsi.cz.		1800	IN	RRSIG	AAAA 5 3 1800 20141004100806 20140904100806 27135 forpsi.cz. TF1AWJD3Wcun92QwS1+ZBy29Zi2qIkBWlYqUeFHGxyQhSlcSAWEt+oOr aTyqk79M38mH7TkFzrCBof+TAc6nM9JSOjm9RfmFQ0FVyM1cpmDxD79W coBeQcGStVofuvdKeuhZG2oiMyBKrbyUFZw1mgI0bupVs1daIy+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.clarion-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 20140924121306 20140825121306 13077 clarion-hotels.cz. M8OQ5fcnOYPX2XXvV9Cgefkjv2AHYFLAMeDfUpBuSk1PBFG6s/4tMSLb C/0r72TOjZupOHe5vizyzamAcE6m7dA4tlXGlWkTapf95lKFRokqjQow 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 20140924121306 20140825121306 13077 clarion-hotels.cz. M8OQ5fcnOYPX2XXvV9Cgefkjv2AHYFLAMeDfUpBuSk1PBFG6s/4tMSLb C/0r72TOjZupOHe5vizyzamAcE6m7dA4tlXGlWkTapf95lKFRokqjQow eRESgmZSS/b43jgxLv/+FRsu3rYnz77j3cC413qBn0PDDKLbepk0YEZC yTk=

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 05 Sep 2014 07:00:16 +1000

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:

;; 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 <[email-masked]>, Viktor Dukhovni writ
es:
>     *.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	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	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.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	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
>     _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=
> 
> 
>     _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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 4 Sep 2014 21:37:31 +0000

> 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?

> 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

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.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 05 Sep 2014 09:05:33 +1000

In message <[email-masked]>, Viktor Dukhovni writ
> (mail2).  This is detected as an error by various validating

Yes.
 
> advice from folks who actually know how this works.

Ok.  Sorry if I came on a bit strong.

---

From: Rene Bartsch <[email-masked]>
Date: Fri, 05 Sep 2014 11:30:06 +0200

When testing avoid to use Google Public DNS resolvers as they have a bug 
in wildcard resolution 
(https://groups.google.com/forum/#!topic/public-dns-discuss/M982l7Lz9uA).

-- 
Best regards,

Rene Bartsch, B. Sc. Informatics

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 5 Sep 2014 15:11:49 +0000

> > (mail2).  This is detected as an error by various validating

Thanks.  I wrote to the operators of the DNS servers, and they are
planning to fix the bug, but implemented a short-term work-around,
where the wildcard CNAME was replaced by wildcard A record.  However
the work-around is not working to the satisfaction of my resolver,
any idea why?

    $ dig +dnssec +norecur -t tlsa _25._tcp.mail2.clarion-hotels.cz @ns.forpsi.net
    ; <<>> DiG 9.8.3-P1 <<>> +dnssec +norecur -t tlsa _25._tcp.mail2.clarion-hotels.cz @ns.forpsi.net
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31810
    ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:

    ;; AUTHORITY SECTION:
    clarion-hotels.cz.      3600    IN      SOA     ns.forpsi.net. admin.forpsi.com. 2014090502 3600 1800 2592000 3600
    clarion-hotels.cz.      3600    IN      RRSIG   SOA 5 2 3600 20141005113302 20140905113302 13077 clarion-hotels.cz. Y4JCzy6U/fMI2tz+pLfQ1mFD2h1jxRMJ7nUwXS0cxlE9xcN8QFibwC75 BBivVbf3Xb2oPXJTRTvkkUAXR1wziOCy/qvK4LyNFX2ENn2aKGn3i93H LrHM/5u1IoeG4niXbS22Tue3FEgYKcSX7UA5PDDQAQs2o+jX9IbwYawC teM=
    *.clarion-hotels.cz.    3600    IN      NSEC    mail.clarion-hotels.cz. A RRSIG NSEC
    *.clarion-hotels.cz.    3600    IN      RRSIG   NSEC 5 2 3600 20141005113302 20140905113302 13077 clarion-hotels.cz. lSf+ySQxo+sXxtuEZEIy7YghFeQnFlDd7vkZA8XO/ahgAzgxHZkAsQXk RjoJVCLd3E3FgX55Pu0RA6IQVn1ynZFYp3l1P24bC93+l3vszNsnMKnD qqjNIIzeYanNfkI34kdPpj5C1HhtrC1ZUhRwryphsKXX9KYFB/B4i+47 U2E=
    mail2.clarion-hotels.cz. 3600   IN      NSEC    clarion-hotels.cz. A RRSIG NSEC
    mail2.clarion-hotels.cz. 3600   IN      RRSIG   NSEC 5 3 3600 20141005113302 20140905113302 13077 clarion-hotels.cz. lX8m4n9dL8/055WYsv5LW/D9L7257lzOv9QAynpBlJiShQkYRFsAc9rT ZFdrCeahWXg01/jGVrUNoxwJUUxUobt8GFcTiXHvI/w5ej6rsc80tUVT BCnW9WsJBNiz7hDN8Ac3V8gKE77Td2TZxJpPtRdAOTW4mc6E04XsLIL7 XmQ=

    ;; Query time: 130 msec
    ;; SERVER: 81.2.194.130#53(81.2.194.130)
    ;; WHEN: Fri Sep  5 11:04:38 2014
    ;; MSG SIZE  rcvd: 742

This time there is no erroneous wildcard CNAME response, just
ANSWER:0, and some NSEC records in the authority section.  In
particular there is an NSEC record that should prove absense of
anything after "mail2", thus denying "_tcp.mail2"...

What's wrong now?  Oddly enough when I ask for "mail3.<etc> IN TLSA
?" the resolver is happy with a "NODATA" response, containing
exactly the same records.  So these records constitute proof that
"mail3" does not exist, but somehow fail to prove that "_tcp.mail2"
does not?

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 5 Sep 2014 16:26:36 +0000

On Fri, Sep 05, 2014 at 03:11:49PM +0000, Viktor Dukhovni wrote:

>     ...

The only slightly odd thing I see is the RRSIG above.  Instead of
binding all three labels of the wildcard, it binds only the last
two.  Is that how it should be?

Anyone have better insight?

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 5 Sep 2014 18:45:28 +0000

> the work-around is not working to the satisfaction of my resolver,

OK, now I understand.  The response is "NODATA", but is should be
"NXDOMAIN".  All that the change did was prevent the wildcard CNAME
being returned incorrectly, but the wildcard record is still
incorrectly processed for the query in question, and incorrectly
returns "NODATA", rather than "NXDOMAIN".

So the work-around is not sufficient.  The real fix is to get the
nameserver to not apply wildcards to subdomains of existent siblings.

I'll try to find out what nameserer software this is, and if
something mainstream, try to let operators know to avoid it.

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 06 Sep 2014 07:39:34 +1000

> the work-around is not working to the satisfaction of my resolver,

The problem is the wildcard and the broken wildcard processing, not
the CNAME.  The rcode is wrong as a result, NOERROR != NXDOMAIN.
Getting rid of the wild card and adding explict address records for
every name the http server is configured fore plus anything else
depending on the wildcard will work.

Alternatively adding a non TLSA records at the expected TLSA names
should work as it should prevent the attempted wilcard lookup in
the server and the resulting mis-match.

_tlsa._tcp.mail.clarion-hotels.cz TXT "-"
_tlsa._tcp.mail2.clarion-hotels.cz TXT "-"

Alternatively they could configure the MTAs to support STARTTLS
and add TLSA records.

Mark

>     clarion-hotels.cz.      3600    IN      RRSIG   SOA 5 2 3600 20141005113302 20140905113302 13077 clarion-hotels.cz.
>  Y4JCzy6U/fMI2tz+pLfQ1mFD2h1jxRMJ7nUwXS0cxlE9xcN8QFibwC75 BBivVbf3Xb2oPXJTRTvkkUAXR1wziOCy/qvK4LyNFX2ENn2aKGn3i93H LrHM
> /5u1IoeG4niXbS22Tue3FEgYKcSX7UA5PDDQAQs2o+jX9IbwYawC teM=
>     *.clarion-hotels.cz.    3600    IN      RRSIG   NSEC 5 2 3600 20141005113302 20140905113302 13077 clarion-hotels.cz
> . lSf+ySQxo+sXxtuEZEIy7YghFeQnFlDd7vkZA8XO/ahgAzgxHZkAsQXk RjoJVCLd3E3FgX55Pu0RA6IQVn1ynZFYp3l1P24bC93+l3vszNsnMKnD qqj
> NIIzeYanNfkI34kdPpj5C1HhtrC1ZUhRwryphsKXX9KYFB/B4i+47 U2E=
>     mail2.clarion-hotels.cz. 3600   IN      RRSIG   NSEC 5 3 3600 20141005113302 20140905113302 13077 clarion-hotels.cz
> . lX8m4n9dL8/055WYsv5LW/D9L7257lzOv9QAynpBlJiShQkYRFsAc9rT ZFdrCeahWXg01/jGVrUNoxwJUUxUobt8GFcTiXHvI/w5ej6rsc80tUVT BCn
> W9WsJBNiz7hDN8Ac3V8gKE77Td2TZxJpPtRdAOTW4mc6E04XsLIL7 XmQ=
> 
>     ;; Query time: 130 msec

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 5 Sep 2014 21:55:46 +0000

> the CNAME.  The rcode is wrong as a result, NOERROR != NXDOMAIN.

Yes, that's it, as I eventually also figured out...

> _tlsa._tcp.mail2.clarion-hotels.cz TXT "-"

Right, indeed:

    _25._tcp.mail.clarion-hotels.cz  IN TXT "No TLSA RRs here yet"
    _25._tcp.mail2.clarion-hotels.cz IN TXT "No TLSA RRs here yet"

should do the job.  Thanks, I'll suggest this to them as a better
interim solution.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 8 Sep 2014 13:38:12 +0000

> Yes, that's it, as I eventually also figured out...

The DNS server in question is djbdns.  Corrected wildcard processing
may be available at <http://www.tinydnssec.org/>, but I've not tested
that software or looked at it in any detail beyond the claim in the
list of improvements that the issue is resolved:

    The interpretation of wildcard records now matches the description
    in RFC-1034 section 4.3.3. Specifically, if there's a wildcard
    *.x and a record for a.x, then a query for y.a.x will not be
    answered using the wildcard (for a label 'a' and series of
    labels 'x' and 'y').  This change is required for signed domains,
    because authentication of negative responses requires a common
    understanding between client and server about the meaning of
    wildcards.

There is an important note about running that software as a secondary:

    Be careful with publishing signed zones as a secondary nameserver:
    the modified tinydns/axfrdns require certain helper RRs in the
    database to simplify locating NSEC3 records. Without these
    helpers, tinydns cannot generate valid negative response nor
    valid wildcard responses.

-- 
	Viktor.