It’s too bad that they apparently don’t offer more hash algorithms.
However the DS hash is derived from the DNSKEY record, so in theory it should be possible to calculate an RSASHA1 DS record given a DNSKEY. Unfortunately I don’t know any tools that might help do this calculation
Is there an alternative to enter the DNSKEY instead of a DS record at OVH? That might let OVH do the calculation for you.
BTW: I’m not familiar with OVH’s UI but “Add a new entry” sounds more like it wants to add a DS record to the zone of your domain, not to the zone of the parent domain? If so, you are using the wrong tool. The zone at OVH is not being used if you have delegated DNS to deSEC. And the chain of trust requires setting the value in the parent zone.
Algorithm 5 is about how the domain is signed, not a hash algorithm for computing the DS record. (There’s also a choice for how to compute the DS record, but that’s the “digest algorithms” which are hash mechanism, rather than “signing algorithms” like RSASHA1.)
You’re correct, I edited my post. And also found a DS 13 2 record in the .top zone.
If OVH still states something like stated in the previous linked community, this counter example should hopefully be enough to reconsider their statement.
Thank you all for your answers. I’m learning more on the subject.
Yes, actually, that’s what I did intuitively. The screenshot of my first post is illustrating the last step of this Case 2, Step 4 help section.
This is the core of my struggle. It seems I can’t satisfy OVH DS Record requirements with deSEC-provided data.
So it seems the issue at hand is not only specific to OVH, but to the combination OVH + .top TLD. Interesting!
As bwb found, a real DS 13 2 record already exists in the .top zone, which proves the registry accepts algorithm 13; making OVH’s constraint the actual blocker.
web API tentative
I also attempted to bypass the web UI limitation using the OVHcloud API (POST /domain/mydomain.top/dsRecord), submitting the DNSKEY directly with algorithm 13. The API returned the same rejection: BadParametersError: 13 is not supported by registry. This confirms the limitation is not a UI issue but is enforced at the OVH backend level, leaving no workaround on the registrant side except for transferring the domain to a registrar with proper algorithm 13 support.
To be continued…
EDIT: I just opened a support ticket at OVH. Let’s see how they react.
It seems different GUI is presented in old version of the OVH manager (and this is the one documented). This one expects Key Tag, has readonly Flag field with value 257, Algorithm drop down with 8, 10, 13-16 and “Public key (encoded in base64)”. The one in beta version of OVH manager has different fields: Key Tag, Algorithm drop down with 8, 10, 13-16 and Public Key field (no longer mentioning base64 but then the shaded sample value is definitely not hexadecimal).
Another one. Encoded hexadecimal key to base64 and it fails validation (wants different value of key tag) - but when I removed padding field validator complained it’s not valid base64. So it seems OVH doesn’t really know what it actually wants from users.
Maybe I just killed my domain but I entered key tag from DS record and base64 value from DNSKEY record presented by deSEC and clicked validate - this saved my value without asking !!
So far I pass all checks on https://dnssec-analyzer.verisignlabs.com except propagation to tld. But I remember from turning this on at previous domain controller that it takes time. So I guess it’s fine? Crazy that I had to piece together information from two types of records.
