<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 4/27/21 22:56, Arne Jensen wrote:<br>
<br>
</div>
<blockquote type="cite"
cite="mid:4211eb31-a738-a562-babf-27d5d693a09d@darkdevil.dk">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p><font face="InputMono-Regular"> In the end, I would simply set
up everything with 14 4, a.k.a. ECDSAP384SHA384, unless any
customers/clients could provide valid justification (including
evidence) why it "cannot" be used, such as e.g. a TLD not
supporting it, could be valid justification to make an
exception for that particular TLD. But in order to make that
exception, there would need to be evidence (from the
customer/client) documenting the claim, so they cannot just go
with "I don't like this algorithm", or other useless crap to
go down to for example SHA1.</font></p>
<p><font face="InputMono-Regular">It would likewise be mandatory,
if I had anything to say, for public sector/government and
financial institutions (banks, card issuers, and so on), to
run DNSSEC and to always secure that they had the strongest
possible algorithms on it.</font></p>
<p><font face="InputMono-Regular"><br>
NB: The reason I'm writing 14 4, a.k.a. ECDSAP384SHA384 all
along is that I've seen DNSSEC signatures with 14 2
(ECDSAP384SHA256), which I would find quite weird.<br>
</font></p>
</blockquote>
<br>
<font face="InputMono-Regular">I've been happy with ECDSAP384SHA384
for a few months now. No issues to report. All works. My registrar
supports it. End of.<br>
<br>
The only other thing I can say to the OP is the whether the
registrar supports the uploading of DS records, or derives the DS
record from the DNSKEY you submit to them. From another list
discussion a while back, the world appears to be split 50/50 on
this.<br>
<br>
Mark.<br>
<br>
</font><br>
</body>
</html>