I think Unbound intentionally wants you to set the trust anchor yourself; their configuration page has specific instructions for doing so and says that enabling DNSSEC is "highly recommended". I think most distributions include the trust anchor as part of their packaging, but if you're compiling it yourself you need to explicitly include it. I'm guessing that Unbound wants you to trust IANA for it rather than themselves.
7 Likes
Unboundtest indeed includes a root.key with the option to use it in the configuration file 
I just hadn't done that on the Unbound running as a service. But that service isn't used by Unboundtest anyway 
4 Likes
Oeeh, Cloudflare by the way adds more info to the EDE field:
; EDE: 6 (DNSSEC Bogus): (failed to verify sigfail.verteiltesysteme.net. A: using DNSKEY ids = [30665])
Unbound doesn't report that verbose.
4 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
Extended DNS Errors are now enabled in our staging environment.
You can see it yourself with a command like
lego -a --http --http.webroot /tmp -d dnssec-failed.org -s 'https://acme-staging-v02.api.letsencrypt.org/directory' run
Which should print an error like:
[dnssec-failed.org] acme: error: 400 :: urn:ietf:params:acme:error:dns :: DNS problem: looking up A for dnssec-failed.org: DNSSEC: DNSKEY Missing; DNS problem: looking up AAAA for dnssec-failed.org: DNSSEC: DNSKEY Missing
I plan to enable this in production soon. Please let me know if you have any feedback.
We've already noted the errors are somewhat verbose for both A and AAAA records, which we might deduplicate if a domain has the same error for both A and AAAA.
9 Likes
YAY
I just played around a little bit and I'm very excited, but boy is it hard to test so I'm not sure it does everything one might hope for. I wish there were more bad-DNSSEC test domains around. I tried some of the CAA Test Suite ones, but I don't know if they're still up-to-date with the correct incorrect statuses, if that makes sense.
certbot certonly --staging --manual --preferred-challenges http -d expired.caatestsuite-dnssec.com
gave me
Domain: expired.caatestsuite-dnssec.com
Type: dns
Detail: DNS problem: looking up A for expired.caatestsuite-dnssec.com: DNSSEC: DNSKEY Missing; DNS problem: looking up AAAA for expired.caatestsuite-dnssec.com: DNSSEC: DNSKEY Missing
But I don't know enough about DNSSEC to say whether "DNSKEY Missing" is the same thing as what CAA Test Suite called "expired", or if the test suite itself isn't having a "correctly" expired signature to give some sort of different message.
Similarly, testing refused.caatestsuite-dnssec.com just gave me a pretty generic the domain's nameservers may be malfunctioning, but again that may be the most correct thing to say.
In any event, I think any sort of message can be helpful to point people closer to the right direction, even if all we can do on this forum is tell people "Your DNS is broken and you need to convince your DNS provider to fix it" just like before.
Your team's faith in your automated testing is very inspiring to me. I mean that quite sincerely; it's quite amazing to take a complete refactoring of your DNS querying and get it into production so quickly, especially when doing DNS queries correctly is one of the main core things that a CA is all about.
7 Likes
Everything seems to be working properly, so this change has been made in production.
5 Likes
Cloudflare has a IMHO pretty good EDE implementation, so I typically use them to cross-check DNS data I see.
dig CAA expired.caatestsuite-dnssec.com +dnssec @1.1.1.1
[...]
EDE: 7 (Signature Expired): (for DNSKEY expired.caatestsuite-dnssec.com., id = 54799: RRSIG expired.caatestsuite-dnssec.com., expiration = 1645039363)
I tried my local Unbound with EDE enables as well and it reports pretty much the same thing:
EDE: 7 (Signature Expired): (validation failure <expired.caatestsuite-dnssec.com. CAA IN>: signature expired from 2606:4700:4700::1111 for key expired.caatestsuite-dnssec.com. while building chain of trust)
refused.caatestsuite-dnssec.com gives a multitude of errors actually:
dig CAA refused.caatestsuite-dnssec.com +dnssec @1.1.1.1
[...]
; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for refused.caatestsuite-dnssec.com.)
; EDE: 22 (No Reachable Authority): (at delegation refused.caatestsuite-dnssec.com.)
; EDE: 23 (Network Error): (128.148.32.121:53 rcode=REFUSED for refused.caatestsuite-dnssec.com CAA)
Unbound on the other hand doesn't appear to send an EDE for unreachable NS servers:
dig CAA refused.caatestsuite-dnssec.com +dnssec @myUnbound
[...]
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20952
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;refused.caatestsuite-dnssec.com. IN CAA
6 Likes
If that's what Unbound reports, then why did Boulder in staging report DNSSEC: DNSKEY Missing for that name?
4 Likes
I investigated this and found out that Unbound appears to respond with inconsistent data depending on configuration:
If I query with only EDE enabled (ede: yes), but extended descriptions disabled (val-log-level: 0) (see the docs here), then I can indeed reproduce Boulder behaviour:
dig CAA expired.caatestsuite-dnssec.com +dnssec @MyUnbound
[...]
; EDE: 9 (DNSKEY Missing)
If I then repeat the query, unbound cache seems to alter the EDE even further:
dig CAA expired.caatestsuite-dnssec.com +dnssec @MyUnbound
[...]
; EDE: 6 (DNSSEC Bogus)
However, when I enable additional descriptions ( val-log-level set to 2), I get a more appropiate EDE code, though actually getting the SERVFAIL takes twice as long:
; EDE: 7 (Signature Expired): (validation failure <expired.caatestsuite-dnssec.com. CAA IN>: signature expired from 45.79.179.40 and 45.79.179.40 for key expired.caatestsuite-dnssec.com. while building chain of trust)
Unboundtest has descriptions enabled, but I'm presuming that the "real thing" has not, since Boulder only appears to care about the code and not about the additional descriptions.
5 Likes
Yeah, we don’t have descriptions enabled. That has some performance overhead so we’ll have to be careful in considering how we do that, which probably isn’t going to happen right now.
Hopefully even without that, it's still enough to help people know it's a DNSSEC-related problem.
7 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.