Strange validation failures for some wildcard CNAMEs

Unbound
1

Hi,

I'm having an issue with validating particular domain names:

$ dig _25._tcp.mail.relia-pc.cz tlsa
$ dig _443._tcp.kinderporno.cz tlsa
- validates with BIND, fails with Unbound 1.4.21
- unbound-host says that cname proof failed

I'm suspecting that there is something wrong on the authoritative side
since both domains are hosted on the same set of servers. But I'm not
able to figure out, what exactly is wrong and how the answers should
look like to be validated successfully by Unbound.

Thanks in advance for any help.

2

I don't immediately see anything wrong with the complete names above. But
I can see that BIND and unbound both are failing validation for _
tcp.kinderporno.cz. I am wondering if this is perhaps due to incorrect
handling of NSEC records associated with wildcards.

$ dig +dnssec +noall +authority @ns.forpsi.it _tcp.kinderporno.cz | grep
NSEC | head -1
default._domainkey.kinderporno.cz. 3600 IN NSEC _jabber._
tcp.kinderporno.cz. TXT RRSIG NSEC

The NSEC record returned doesn't prove that the name doesn't exist
(NXDOMAIN) because the name (_tcp.kinderporno.cz) is in fact an ancestor of
the next field of the NSEC record (_jabber._tcp.kinderporno.cz), as an
empty non-terminal. But that proof is not required for wildcard, only for
NXDOMAIN status.

But that doesn't explain why unbound would be failing validation on _443._
tcp.kinderporno.cz, unless it is performing validation of _
tcp.kinderporno.cz along the way.

Just a guess.

Casey

3

Dne 17.9.2014 16:05, Ondřej Caletka napsal(a):

Hi,

I'm having an issue with validating particular domain names:

$ dig _25._tcp.mail.relia-pc.cz tlsa
$ dig _443._tcp.kinderporno.cz tlsa
- validates with BIND, fails with Unbound 1.4.21
- unbound-host says that cname proof failed

I'm suspecting that there is something wrong on the authoritative side
since both domains are hosted on the same set of servers. But I'm not
able to figure out, what exactly is wrong and how the answers should
look like to be validated successfully by Unbound.

Hello again,

I think I've found answer in DANE WG ML:
http://www.ietf.org/mail-archive/web/dane/current/msg06960.html

Looks like the issue is actually caused by bad wildcard DNSSEC
processing in djbdns.

Thanks for help.

4

For archival purposes, the above guess was incorrect, due to an overlooking
of proper server-side wildcard processing behavior from RFC 1034, as
indicated by Ondřej, who posted reference to the same issue on the DANE WG
mailing list. In this case, the wildcard should never have been expanded
because an ancestor of the name exists.

Casey