DNSSEC 'DS' record set at registrar is valid but should be updated to ECDSAP256SHA25

Just updated to v0.54, and now I’m getting the following message on System Status Checks.

DNSSEC 'DS' record set at registrar is valid but should be updated to ECDSAP256SHA256 (see below). Follow the instructions provided by your domain name registrar to set a DS record. Registrars support different sorts of DS records. Use the first option that works: Option 1:

My DNS registrar is Hover.

Is this related to the upgrade to v0.54?

Yes, this is mentioned in the changelog:

The ECDSAP256SHA256 DNSSEC algorithm is now available. If a DS record is set for any of your domain names that have DNS hosted on your box, you will be prompted by status checks to update the DS record at your convenience.

Note I haven’t updated, yet, so haven’t gone through the details of it.

Thank you! I was able to use Hover’s ADVANCED page to set an active DNSSEC Record to Option 1 recommended by MiaB System Status Checks, and it worked!

2 Likes

I’m guessing option 1 is ECDSA and option 2 is RSA?

Hello, I have the same issue: DNSSEC ‘DS’ record set at registrar is valid but should be updated to ECDSAP256SHA256 (see below). One of my DNS registrar is whois.com. The support team used option 7 to update, they told, but nothing has changed. What’s the matter? Is option 7 the correct one to to be updated to ECDSAP256SHA256? The other registrar is Swizzonic, and there I could simply replace the old record to the new one, and it worked at once !!!

Option 7 uses RSASHA1-NSEC3-SHA1, which is the algorithm MiaB is migrating away from because it is not recommended for signing according to RFC.

Also according to RFC, registrars are supposed to follow the RFCs, but they never do, especially when it comes to DNSSEC.

2 Likes

Thanks a lot for this hint. I will forward this notice to Whois.com support. Unfortunately, I don’t know exactly which RFC you mean here.

It is in RFC8624.

https://datatracker.ietf.org/doc/html/rfc8624#section-3.1

1 Like

Now, since the algorithm 13 is not working for MiaB, they request me to provide whois.com with the details provided in this image: https://i.vgy.me/dIsYhs.png
I had the same problem just one year ago, and they are not able to do it again?

Shocking fact: now DNSSEC has suddenly been deactivated for the domain !!! Nothing works anymore! What’s going on there?

I’m not sure what they mean by Flags. Of course it is going to be KSK, but that shouldn’t be an actual part of the record. They don’t provide anywhere to put the tag, so I wonder if Flags is supposed to be the tag?

That is a strange form.

You could also switch to a different registrar.

Maybe they want to wear down little fish like me. I’ve been working as a computer scientist for 41 years, but I’ve never experienced anything like it. I hope that you will not experience that, over time, you will be booted out by AI robots.

A post was split to a new topic: Help setting up DNSSEC in AWS

My registrar’s support team asks me to provide a ‘protocol’. But they cannot explain me which ‘protocol’ this is about. Does anyone have any idea?

Here is an example of what Name.com’s DNSSEC entry page looks like,

So the algorithim will be #13 or #14.

They should require an ‘algorithm’ or a ‘digest type’ … ‘protocol’ is not a term used for DNSSEC.

Thanks for your help. I’ve forwarded it to the support.

Thanks for your help. I’ve forwarded it to the support.

When you are sending a support ticket related to creating a DS record, you could use the Bulk/Record format stated in the MiaB interface as this is a standardized notation, so even when the support drone doesn’t know what you are talking about, as long as the admin under the labyrinth can receive the message intact, they should know what to do with it.

example.com.	3600	IN	DS	60485	13	2	24899c19b3fd48722974148c0f8bb5f6c8eab339948386d11ee1d52d65cfc303

:upside_down_face:
Thanks, I delivered the Buld/Record format of option 1 and alternatively option 2

In the meantime I was able to find out what the Whois support understands by ‘Protocol’: rfc4034.
Section 2.1.2.