DNSSEC signature problem for non-existent CAA record #696
Comments
|
Oh, I should mention darkspirit.eu doesn't use sqlite and is also affected: |
|
Am I understanding correctly that NSEC is not being returned on the response for www2 and CAA? Or is it that the RRSIG being returned for the NSEC is incorrect? |
|
I try to get the best out of my incompetence and provide a direct comparison to PowerDNS: Inexisting subdomain within existing zone: Existing subdomain (AAAA) with inexisting record type CAA: |
Darkspirit
changed the title
|
Ok, we'll need some logs from the server. We're getting a $> dig +dnssec +tcp www2.ikenmeyer.eu CAA
; <<>> DiG 9.10.6 <<>> +dnssec +tcp www2.ikenmeyer.eu CAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9600
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;www2.ikenmeyer.eu. IN CAA
;; Query time: 947 msec
;; SERVER: 2001:558:feed::1#53(2001:558:feed::1)
;; WHEN: Thu Feb 28 06:04:28 PST 2019
;; MSG SIZE rcvd: 46Could you enable debug logs, send the startup section and then the request section for the above dig request? |
|
Server: Laptop with Debian Testing (having a local unbound through dnssec-trigger): The single CAA request at end of debug.log was made by this command and directly to @ns1.darkspirit.eu: |
|
ok, thanks. I thought we were seeing a different issue, but it looks like the SERVFAIL was from an intermediate resolver, rather than the trust-dns server. here's what I think is going on: https://github.com/bluejekyll/trust-dns/blob/master/crates/server/src/authority/catalog.rs#L416-L435 That section adds the |
|
@Darkspirit want to try out #697 and see if it resolves this issue? |
|
"Suspicious or confusing response received."
|
|
Hmm. Looks like DNSSEC flag isn’t being set. I can’t post a fix right now, will as soon as I can. |
|
@Darkspirit I haven't merge #697 into master yet, are you using the |
|
I reverted to master after your reply, as
|
|
Ok, thanks. I need to go back and double check the RFCs for NSEC. |
|
So The NSECs are supposed to be in the Authority/Nameserver section of the response. So that looks like it was correct originally. It looks like the authoritative flag wasn't being set in a NODATA/NXDOMAIN response. I've made sure that's always set now, it that same branch. I don't know if that's the only patch, needed, but I didn't see anything else that seemed wrong. I need to double check if the authoritative flag should be false in the NXDOMAIN case, which it might be, so this might still be wrong. |
|
Recompiled and live. Existing subdomain (AAAA) with inexistent record type (CAA) PowerDNS for comparison: Inexistent subdomain https://dnssec-analyzer.verisignlabs.com/www2.ikenmeyer.eu
PowerDNS for comparison: Cloudflare for comparison: |
|
So it looks like we need an additional NSEC record for the result. trust-dns is only responding with a single NSEC record, while it appears we need two. I'm reviewing this: https://tools.ietf.org/html/rfc4035#section-3.1.3 to see what is wrong. Ok, this is what we've gotten wrong, the wildcard name error response We're not including that second record. |
|
Ok, new change is up that has the wildcard nsec proof included. I still need to add a test case for this. |
|
That fixed
|
|
Btw, it seems that Cloudflare handles NSEC a bit special: https://blog.cloudflare.com/black-lies/
Inexistent subdomain ;; OPT PSEUDOSECTION: ;; AUTHORITY SECTION: ;; Query time: 40 msec Existing subdomain (AAAA/A) with inexistent record type CAA ;; OPT PSEUDOSECTION: ;; AUTHORITY SECTION: ;; Query time: 37 msec |
|
It appears that one issue we have is that the NSEC record isn't marking itself as covered. Based on that result, It looks like cloudflare is generating a null record to mark that thee is no subzone under the www record, which might be to attempt to prevent zone walking? What I see in the initial NXDOMAIN response is similarly interesting, because it appears they're generating an NSEC record on the fly for that query. Both of these are interesting, and would take a bit longer for a patch. I'll need to review what cloudflare is doing here, and see if we can use similar techniques (though generating NSEC on the fly could be a source of DOS attacks). |
|
Ok, I pushed the fix for the NSEC record not covering itself. |
|
Looks unchanged: http://dnsviz.net/d/www2.ikenmeyer.eu/dnssec/ (terrax.net is no longer a PowerDNS example as everything has been switched to Trust-DNS by now. Other PowerDNS example: http://dnsviz.net/d/asdf.powerdns.org/dnssec/) |
|
paying more attention to my test cases, I appear to have broken something. I'll work to get to the bottom of this. |
|
Ok, I patched up the construction of the NSEC records, but I'm not sure it will fix the original issue, but it does resolve one that was introduced in this patch. I'm thinking that we might want to look into implementing the same DNSSEC mechanism as cloudflare: https://blog.cloudflare.com/dnssec-done-right/ edit: opened #706 for this |
|
Same as before. |
|
I’m wondering if there’s a bug in the returned NSEC records and their ordering with the _dmarc record in you example zones. I’ll investigate that code a little more. edit: ok, yes, I think I finally tracked down this issue and have reproducible test case. but I've run out of time to fix it this morning. |
|
Ok, @Darkspirit, I'm hoping the patch I just pushed resolves all the remaining issues. |
|
I have no idea and it's still broken. But PowerDNS and ISC first respond with their SOA. shrinked ikenmeyer.com zone: http://dnsviz.net/d/asdf.ikenmeyer.com/analyze/
dig +nocmd +dnssec +tcp asdf.ikenmeyer.com A @ns1.darkspirit.eu ;; OPT PSEUDOSECTION: ;; AUTHORITY SECTION: ;; Query time: 47 msec dig +nocmd +dnssec +tcp asdf.isc.org A @ams.sns-pb.isc.org. ;; OPT PSEUDOSECTION: ;; AUTHORITY SECTION: ;; Query time: 28 msec dig +nocmd +dnssec +tcp asdf.powerdns.org A @xs.powerdns.com. ;; OPT PSEUDOSECTION: ;; AUTHORITY SECTION: ;; Query time: 34 msec |
|
It seems putting the SOA first was not enough to fix the problem. What a beast. |
|
Wait, is the status code wrong? trust-dns is responding with a NOERROR, the other examples you have there are NXDOMAIN... edit: yes, see examples here: https://tools.ietf.org/html/rfc4035 I'm not sure how I misread that and was intentionally making that switch... I even had a test validating that. Interesting. |
|
Just pushed the change, 8th time's the charm? |
|
Mostly! :) But dnsviz complains here:
|
|
At least we’re finally making progress! This appears to be a general issue with NXDOMAIN vs. NOERROR responses. It might take me a bit to figure out how to resolve this one. |
|
Just pushed a patch, @Darkspirit, that should resolve the most recent issue you found. |
|
Thank you, it looks like everything is fixed, I haven't found other bugs so far! :) |
|
Thank you for verifying and working with me on this! |
|
This one is still reporting an error: http://dnsviz.net/d/terrax._domainkey.ikenmeyer.eu/XIFnsQ/dnssec/ Edit: oh I’m guessing you haven’t updated that zone yet. |
|
That's just a link to the (old) cached result. |
|
Ok, I want to clean up a few things, then I'll merge this in. Thanks, again! |
I noticed that Let's Encrypt fails to issue a certificate for a subdomain that doesn't have a CAA record.
Acme challenges themselves work smooth.
"DNSSEC validation failure"
Existing subdomain (AAAA) with inexisting record type (CAA):
https://dns.google.com/query?name=www2.ikenmeyer.com&type=CAA&dnssec=true
(http://dnsviz.net/d/www2.ikenmeyer.com/dnssec/)
Inexisting subdomain:
https://dns.google.com/query?name=www2.ikenmeyer.eu&type=CAA&dnssec=true
This looks very broken: http://dnsviz.net/d/www2.ikenmeyer.eu/dnssec/
NSEC proving non-existence of www2.ikenmeyer.eu/A: No NSEC RR matches the SNAME (www2.ikenmeyer.eu).www2.ikenmeyer.eu/A (NODATA): The Authoritative Answer (AA) flag was not set in the response.An existing CAA record is fine of course:
https://dns.google.com/query?name=www.ikenmeyer.com&type=CAA&dnssec=true
This problem occurs both with OpenSSL and ring.
It could be related to a different problem I observed while setting a low "Negative TTL" value:
http://dnsviz.net/d/ikenmeyer.eu/dnssec/
RRSIG ikenmeyer.eu/SOA alg 14, id 8974: The TTL of the RRSIG RR (600) does not match the TTL of the RRset it covers (86400).Lowering SOA TTL (86400) to the value of Negative TTL (600) doesn't seem to help either.
Debian Testing:
Binary compiled with:
cargo install trust-dns-server --git https://github.com/bluejekyll/trust-dns --rev 8a3130976acb9e9219da7e516c4f850dc91c75e4 --features "dnssec-ring dnssec-openssl" --forceKeys generated with:
openssl ecparam -out keys/p384.pem -name secp384r1 -genkeykt generate p384 --out keys/ikenmeyer.eu.pk8Journals have been deleted before starting the server. Start command is basically:
/home/trustdns/named --config=/home/trustdns/config.toml --zonedir=/home/trustdns/zones//home/trustdns/config.toml
/home/trustdns/zones/ikenmeyer.com
/home/trustdns/zones/ikenmeyer.eu
The text was updated successfully, but these errors were encountered: