[dns-operations] any registries require DNSKEY not DS?
Tony Finch
dot at dotat.at
Thu Jan 23 00:12:15 UTC 2020
Warren Kumari <warren at kumari.net> wrote:
>
> I believe that at least SIDN used to (and perhaps still does) - this
> was one of the reasons that the CDS record is actually CDS/CDNSKEY.
>
> When I first heard this I was confused as to why they'd do this -- but
> then Antoin Verschuren / Cristian explained that they'd like to make
> sure that a good hash is being used, and suddenly I started wondering
> why this isn't the default...:-)
In fact I have made use of this! In more than one way!
I did some work on BIND last year to implement RFC 8624 section 3.3 -
death to SHA-1 DS records! But I left out the dnssec-cds utility
(parent-side implementation of RFC 7344) which already defaulted to
SHA-256. However during my cam.ac.uk algorithm rollover project
(remember, folks, RSASHA1 is shafted) I found a lacuna:
By default dnssec-cds copies CDS records to make DS records, and the
question of SHA-256 or something else only arose when it was asked to turn
CDNSKEY records into DS records. But if the CDS records are generated by
some ancient code from before the dawn of time, such as BIND 9.14 on my
production servers, there will be SHA-1 CDS records which will be copied
to the DS records. Sadface, RFC 8624 protocol violation.
So I fixed dnssec-cds to filter out SHA-1 CDS records.
And, if the child turns out to have been so foolish as to use only SHA-1,
dnssec-cds will now fall back to using the CDNSKEY records to make SHA-256
DS records instead.
In production for my child zones I've faked this by telling dnssec-cds
(9.14 sans patch) to only look at CDNSKEY records.
All in all this is a practical example of daddy knows best wrt choice of
DS digest types.
Tony.
--
f.anthony.n.finch <dot at dotat.at> http://dotat.at/
Faeroes: Southwest 6 to gale 8, veering west 7 to severe gale 9. Very rough or
high. Rain then wintry showers. Good, occasionally poor.
More information about the dns-operations
mailing list