DNSSEC validaion fail for _25._tcp.eldinhadzic.com

Hello,

with unbound-1.5.9, we hit $subject. The domain is signed using algorithm 14.
( http://dnsviz.net/d/_25._tcp.eldinhadzic.com/dnssec/ )

# posttls-finger eldinhadzic.com
posttls-finger: warning: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25._tcp.eldinhadzic.com type=TLSA: Host not found, try again
posttls-finger: warning: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25._tcp.eldinhadzic.com type=TLSA: Host not found, try again
posttls-finger: Failed to establish session to eldinhadzic.com via eldinhadzic.com: TLSA lookup error for eldinhadzic.com:25

unbound logs:
[1468570247] unbound[31749:0] notice: init module 0: validator
[1468570247] unbound[31749:0] notice: init module 1: iterator
[1468570247] unbound[31749:0] info: start of service (unbound 1.5.9).
[1468570251] unbound[31749:0] info: ::1 eldinhadzic.com. MX IN
[1468570251] unbound[31749:0] info: ::1 eldinhadzic.com. A IN
[1468570251] unbound[31749:0] info: ::1 eldinhadzic.com. AAAA IN
[1468570251] unbound[31749:0] info: ::1 _25._tcp.eldinhadzic.com. TLSA IN
[1468570252] unbound[31749:0] info: validation failure <_25._tcp.eldinhadzic.com. TLSA IN>: nameerror proof failed from 176.124.112.100
[1468570252] unbound[31749:0] info: ::1 _25._tcp.eldinhadzic.com. TLSA IN
[1468570252] unbound[31749:0] info: validation failure <_25._tcp.eldinhadzic.com. TLSA IN>: nameerror proof failed from 176.124.112.100
[1468570252] unbound[31749:0] info: ::1 _25._tcp.eldinhadzic.com. TLSA IN
[1468570252] unbound[31749:0] info: validation failure <_25._tcp.eldinhadzic.com. TLSA IN>: nameerror proof failed from 176.124.113.200
[1468570252] unbound[31749:0] info: ::1 _25._tcp.eldinhadzic.com. TLSA IN
[1468570252] unbound[31749:0] info: validation failure <_25._tcp.eldinhadzic.com. TLSA IN>: nameerror proof failed from 176.124.113.200
[1468570252] unbound[31749:0] info: ::1 _25._tcp.eldinhadzic.com. TLSA IN
[1468570252] unbound[31749:0] info: validation failure <_25._tcp.eldinhadzic.com. TLSA IN>: nameerror proof failed from 2a05:b0c1::200
[1468570252] unbound[31749:0] info: ::1 _25._tcp.eldinhadzic.com. TLSA IN
[1468570253] unbound[31749:0] info: validation failure <_25._tcp.eldinhadzic.com. TLSA IN>: nameerror proof failed from 2a05:b0c0::100
[1468570253] unbound[31749:0] info: ::1 _25._tcp.eldinhadzic.com. TLSA IN
[1468570253] unbound[31749:0] info: validation failure <_25._tcp.eldinhadzic.com. TLSA IN>: nameerror proof failed from 176.124.112.100
[1468570253] unbound[31749:0] info: ::1 _25._tcp.eldinhadzic.com. TLSA IN
[1468570253] unbound[31749:0] info: validation failure <_25._tcp.eldinhadzic.com. TLSA IN>: nameerror proof failed from 2a05:b0c1::200

DNSVIZ say it's valid: http://dnsviz.net/d/_25._tcp.eldinhadzic.com/dnssec/
how can I check my unbound could validate such data at all?

# unbound -h
...
Version 1.5.9
linked libs: libevent 2.0.21-stable (it uses epoll), OpenSSL 1.0.1t 3 May 2016
linked modules: dns64 validator iterator
...

I have also ldns-keygen which at least 'know' about that algorithm:

# ldns-keygen -a list
Possible algorithms:
RSAMD5
RSASHA1
RSASHA1-NSEC3-SHA1
RSASHA256
RSASHA512
ECDSAP256SHA256
ECDSAP384SHA384
DSA
DSA-NSEC3-SHA1
hmac-md5.sig-alg.reg.int
hmac-sha1
hmac-sha256

Andreas

A. Schulze:

with unbound-1.5.9, we hit $subject.

"qname-minimisation" was enabled. Everything is fine if I disable the feature.

# posttls-finger eldinhadzic.com
posttls-finger: using DANE RR: _25._tcp.eldinhadzic.com IN TLSA 2 1 2 77:4F:AD:8C:9A:6A:FC:2B:DB:44:FA:BA:83:90:D2:13:AE:59:2F:B0:D5:6C:5D:FA:B1:52:28:4E:33:4D:7C:D6:AB:D0:57:99:23:6E:7A:A6:26:6E:DF:81:90:7C:60:40:4C:57:EE:54:C1:0A:3A:82:FC:C2:A9:14:66:29:B1:40
posttls-finger: using DANE RR: _25._tcp.eldinhadzic.com IN TLSA 3 1 2 22:B8:28:3F:A6:10:61:63:EC:40:89:0A:2D:B9:1A:6E:6F:22:BB:91:F2:12:0A:89:3D:94:A0:12:C0:2F:D5:5C:4F:1D:B8:BE:27:6C:CD:FB:D4:C2:0A:C8:79:BC:03:0F:FA:6C:15:0B:85:94:E1:F4:5B:56:B1:92:7D:D7:6D:A9
...
posttls-finger: Verified TLS connection established to eldinhadzic.com[163.172.141.143]:25: TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)
...

also unbound log looks better:
[1468571689] unbound[2046:0] notice: init module 0: validator
[1468571689] unbound[2046:0] notice: init module 1: iterator
[1468571689] unbound[2046:0] info: start of service (unbound 1.5.9).
[1468571693] unbound[2046:0] info: ::1 eldinhadzic.com. MX IN
[1468571693] unbound[2046:0] info: ::1 eldinhadzic.com. A IN
[1468571693] unbound[2046:0] info: ::1 eldinhadzic.com. AAAA IN
[1468571693] unbound[2046:0] info: ::1 _25._tcp.eldinhadzic.com. TLSA IN

Andreas

Hi Andreas,

You have enabled qname-minimisation. And the server does not support
queries for _tcp.eldinhadzic.com.

The answer for _tcp.eldinhadzic.com. is NXDOMAIN. And the DNSSEC
proof for it is broken. For _25._tcp TLSA there is a TLSA answer,
dnssec valid, this is what people without qname minimisation get.

The server says it is
version.bind. 5 CH TXT "Rage4 DNS - https://rage4.com"
and soa record also talks about rage4.
eldinhadzic.com. 3600 IN SOA ns1.r4ns.com.
postmaster.eldinhadzic.com. 1468246877 10800 3600 604800 3600
I guess they have their own implementation.

But it gives NXDOMAIN for empty nonterminals. And the proof for that
NXDOMAIN is then broken.

The proof has the nsec3 for the zone apex, as the closest encloser.
The next closer, _tcp, there is no covering nsec3 for it.

The other nsec3s in the packet are the covering nsec3s that prove that
the names _25._tcp and *._25._tcp do not exist. That would prove an
NXDOMAIN for _25._tcp, but these nsec3s are pointless here.

What with doing TLSA for their mail, perhaps the domain owners want
working DNSSEC too? :slight_smile:

Best regards, Wouter

I reported a different DNSSEC bug in Rage4 DNS two years ago, and they
were very responsive and fixed it within a day - I sent the bug report to
office@gbshouse.com (I can't remember where I got that address from I'm
afraid...)

Back then Rage4 DNS was a customized version of PowerDNS 3.1, so you might
find a bug fix which matches this failure in the PowerDNS changelog.

Tony.

I've added some checks to DNSViz to flag problems with ancestor names:

http://dnsviz.net/d/_25._tcp.eldinhadzic.com/V4iWzQ/dnssec/

Hope that helps for future troubleshooting.

Casey

Casey Deccio via Unbound-users writes:

> > DNSVIZ say it's valid:
> > http://dnsviz.net/d/_25._tcp.eldinhadzic.com/dnssec/
> > how can I check my unbound could validate such data at all?
> >
> >
> I've added some checks to DNSViz to flag problems with ancestor names:
>
> http://dnsviz.net/d/_25._tcp.eldinhadzic.com/V4iWzQ/dnssec/
>
> Hope that helps for future troubleshooting.

Nice!

  jaap

Casey,

that _really_ helps. Many Thanks!

Andreas