I’m a user of the 1.1.1.1 dns and very happy about it. However, one website does not work and that is the one from my health care insurer: www.menzis.nl This is also the reason their app does not function.
Took me some time to understand it’s a dns issue.
I am absolutely not an expert. Where can I identify the problem exactly and can what can I do or report to solve it?
Related thread:
But I don’t understand why Cloudflare does not validate it. Here are the DS records:
menzis.nl. 3600 IN DS 64964 8 2 F2282173D4BE80DE5CA278C4B5330F02A8F26D24F871163C6F38F09C BB5C5C9A
menzis.nl. 3600 IN DS 55380 8 2 1999C15612FEDB367D13B4A9BB48B5F6E7650E17302C12E2FB611642 7A6B1910
menzis.nl. 3600 IN DS 11219 8 2 003CF0ADF398580E3D4F58FD7353860B623B7EDB89DC018F85B3A1AD 9016961B
Only 64964 is valid, which uses algorithm 8 (RSA/SHA-256) and digest type 2 (SHA-256). The key length is 512 bits, which is probably too low for Cloudflare’s DNSSEC validator. Still, serving a SERVFAIL for failing an arbitrarily set key length requirement seems ridiculous for me. RFC5702 specifies that the key size of RSA/SHA-256 keys MUST NOT be less than 512 bits and MUST NOT be more than 4096 bits. 512 bits is perfectly valid, however, probably unsafe as it can be factorised in a couple of hours.
In the previous thread, the particular domain got completely removed from DNSSEC validation to fix the issue. But I do not understand this. There are thousands of sites which still have 512 bits key lengths, are we going to wait until every user reports them to Cloudflare so a manual bypass can be added for that particular domain? Why can’t there be a one-fix-all solution? Why not just bypass/ignore validation for all 512 bits keys? The domain resolves on all big public DNSSEC enabled resolvers, why not Cloudflare?
Seems to resolve as of today:
; <<>> DiG 9.16.22-Debian <<>> menzis.nl @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56564
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 1 (Unsupported DNSKEY Algorithm): (unsupported key size, DNSKEY menzis.nl., id = 64964)
;; QUESTION SECTION:
;menzis.nl. IN A
;; ANSWER SECTION:
menzis.nl. 86395 IN A 194.26.147.1
;; Query time: 11 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed Jan 19 19:04:41 CET 2022
;; MSG SIZE rcvd: 111
Hi! These should be resolved for all these cases. This issue is when there’s a delegation with DS covering multiple keys, but not all of the keys are retrievable and the only usable key is insecure (in this case 512b RSA). This is not how you should do key rollovers, but failing in this case is not great for end users either.
RFC4035 allows downgrading to insecure when:
If the validator does not support any of the algorithms listed in an
authenticated DS RRset, then the resolver has no supported
authentication path leading from the parent to the child. The
resolver should treat this case as it would the case of an
authenticated NSEC RRset proving that no DS RRset exists, as
described above.
However it’s not clear what should happen when the algorithm is supported, but the key sizes are out of bounds.
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.