Broken DNS or broken Unbound?

Can anyone explain what is going on with the domain matt.io? I'm running
Unbound 1.4.9 and have it set up to do DNSSEC validation. "dig matt.io"
SERVFAIL's, however "dig +cd matt.io" works fine. This domain doesn't
have DNSSEC on it though... I also noticed that when I attempt to look
up the NS records, all it returns is a CNAME. Is that valid?

Is matt.io's DNS configuration broken, or is Unbound broken?

Hi Mike,

The DNS setup of matt.io is broken. They've made the well-known
mistake of mixing a CNAME record with other records:

; <<>> DiG 9.7.3-P3 <<>> +norec ns matt.io @DNS1.NAME-SERVICES.COM
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17082
;; flags: qr aa; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 5

;; QUESTION SECTION:
;matt.io. IN NS

;; ANSWER SECTION:
matt.io. 1800 IN CNAME eb.blagomatic.com.
matt.io. 3600 IN NS dns1.name-services.com.
matt.io. 3600 IN NS dns2.name-services.com.
matt.io. 3600 IN NS dns3.name-services.com.
matt.io. 3600 IN NS dns4.name-services.com.
matt.io. 3600 IN NS dns5.name-services.com.

Regards,

Anand Buddhdev
RIPE NCC

Ah, I see. I'll contact him and let him know. Can anyone explain why
these two results differ for me?

mike@server:~$ dig +short ns matt.io
mike@server:~$ dig +short +cd ns matt.io
eb.blagomatic.com.
mike@server:~$

I understand that his zone is broken, but why does that make Unbound
return a different response depending on whether or not DNSSEC is
enabled? He might have noticed this problem earlier if Unbound refused
to return an address even with DNSSEC disabled...

Is matt.io's DNS configuration broken, or is Unbound broken?

The DNS setup of matt.io is broken. They've made the well-known
mistake of mixing a CNAME record with other records:

Unfortunately, this scenario (CNAME and other data, particularly at the zone apex) is increasingly common as a result of web hosting scenarios despite the restrictions in the DNS specs. There was at least on attempt to standardize behavior (http://tools.ietf.org/html/draft-sury-dnsext-cname-at-apex-00), but I gather it withered on the vine.

Ah, I see. I'll contact him and let him know. Can anyone explain why
these two results differ for me?

mike@server:~$ dig +short ns matt.io
mike@server:~$ dig +short +cd ns matt.io
eb.blagomatic.com.
mike@server:~$

I understand that his zone is broken, but why does that make Unbound
return a different response depending on whether or not DNSSEC is
enabled? He might have noticed this problem earlier if Unbound refused
to return an address even with DNSSEC disabled...

Since CNAME and other data is explicitly disallowed in RFC 1035, any behavior, up to and including packets exploding in an Earth-Shattering Kaboom, should't be surprising. I'd agree that the inconsistency between DNSSEC/non-DNSSEC is unexpected, but you know what they say about the Spanish Inquisition...

Regards,
-drc

* Mike Cardwell:

I understand that his zone is broken, but why does that make Unbound
return a different response depending on whether or not DNSSEC is
enabled?

This behavior is triggered as soon as the parent zone is signed.

This has been discussed before:

<http://comments.gmane.org/gmane.network.dns.unbound.user/1296&gt;