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.
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.
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
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.
Interesting. That’s for the DNSKEY record type. With Mail-in-a-Box, the Mail-in-a-Box (not the registrar) creates the DNSKEY records, so this field should not be used to set up DS records at the registrar.
Hi mskendrick,
I did notice the same thing after the upgrade to v0.54 and did upgrade the DNSSEC keys at the registrar ( GoDaddy in my case ). All went fine for TLDs: .net, .co.uk, .me, and all validated during the checks.
But for TLD .pro the registrar or I guess the root servers? does not support Option 1&2 (Algorithm: 13 / ECDSAP256SHA256 ).
So I did update with the next available one - Option 3 Algorithm: 8 / RSASHA256 with Digest Type: 2 / SHA-256 and it does pass the validation fine here and locally with dig as well, but MIAB still does not seem to like it when it does run the “System Status Checks” and prompts for an update…huh
? DNSSEC 'DS' record set at registrar is valid but should be updated to ECDSAP256SHA256 (see below).
I’ll ignore it for now, as I know it’s valid, but this “advisory” it’s just drive me nuts
Cheers,
I use Epik as my registrar and their DNSSEC UI had no way to properly configure any of the options. I uploaded the entire miab message with all options to support and they changed it. It worked!
Just to let folks know that I updated my DNSSEC protocols with Gandi.net and it was very straightforward. The Gandi user interface is very easy to use. Selecting the correct protocol is very easy.
One thing to note. I believe that you should add the new records and check they work (by looking at the MIAB admin panel) before deleting the old records.
It took only a few minutes for the records to update when set at Gandi. The whole process for 6 domains took only about 15 minutes in total; I updated and checked them one at a time starting with my less critical domains.
Also Namecheap and NameSilo are both very easy to use.
There is an RFC somewhere that outlines how to migrate DNSSEC DNSKEY/DS “RRsets”, and it includes not deleting the old RRset before verifying the new RRset works.