In addition to my previous e-mail: After some more research I found out that this issue has nothing to do with my own ODS instance. It is actually an RFC8624 compliance issue of TransIP. It seems that TransIP generates a SHA-1 hash and delivers this to the .COM and .NET registries. I already opened a support ticket asking them to fix this. The problem does not exists for .NL domains since SIDN calculates their own DS hashes. > -----Oorspronkelijk bericht----- > Van: Opendnssec-user <[email protected]> > Namens Dennis Baaten via Opendnssec-user > Verzonden: dinsdag 2 februari 2021 20:08 > Aan: '(Berry) A.W. van Halderen' <[email protected]> > CC: [email protected] > Onderwerp: Re: [Opendnssec-user] Change DS algorithm type > > Hi Berry, > > > -----Oorspronkelijk bericht----- > > Van: (Berry) A.W. van Halderen <[email protected]> > > Verzonden: dinsdag 2 februari 2021 00:26 > > Aan: [email protected] > > CC: [email protected] > > Onderwerp: Re: [Opendnssec-user] Change DS algorithm type > > > > Dear Dennis, > > > > On Mon, Feb 01, 2021 at 11:21:30AM +0100, Dennis Baaten via > Opendnssec- > > user wrote: > > > When performing tests using DNSViz.net, the algorithm used for creating > > the > > > DS is shown: Digest type / Digest alg. For the record: this is not the > same > > > as the DNSSEC algorithm > > > (https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg- > > numbers.xh > > > tml). > > > As the DS Digest type is currently set to "1" (which is SHA-1) I would > like > > > to change this in my ODS configuration. However, I cannot find any > > > documentation on how to change this and which values are supported. > > RFC5155 > > > only mentions SHA-1: https://tools.ietf.org/html/rfc5155#section-11. > > > My guess is that it is related to this section in kasp.xml: > > > <NSEC3><HASH><Algorithm>1</Algorithm></HASH></NSEC3>. If so, > then > > I'm also > > > guessing (based on testing other domains using DNSViz) that I can change > > > this to "2" being SHA-256. > > > > The hash for generating a DS is something different from the hash used in > > NSEC3 records. A DS record points to a DNSKEY record by hashing it. > > This needs to be secure, so yes a SHA-1 hash no longer suffices. > > OpenDNSSEC no longer outputs SHA-1 hashes unless you explicitly request > it > > to do so. Getting a hash as soon as a new KSK is ready is obtained by > > > > ods-enforcer key export -z example.com --ds > > > > If the KSK is already active you will have to use an additional -e flag. > > Thnx for explaining. So it is not the <NSEC3> section in kasp.xml. However, > it is still unclear to me how to change the hashing algorithm used for the > DS record. I don't see anything for that in the ODS config files. I'm also > not aware of forcing the use of SHA-1 since you state that ODS only does > this when explicitly requested. If I export the DS using " ods-enforcer key > export --zone baaten.com --keystate active --keytype ksk --ds" the output > states "active KSK DS record (SHA256)" and the exported hash is 64 hex > characters long, which is the correct length (a SHA-1 hash would be 40 hex > characters long). > > Since I'm using TransIP as a hosting provider, I have to submit the public > key of my KSK in the TransIP control panel which is then submitted to the > parent zone. This is documented here > (https://www.transip.nl/knowledgebase/artikel/150-domeinnaam- > nameservers-geb > ruikt-beveiligen-dnssec/) in Dutch. There is no option to also submit the DS > hash from the ods-enforcer export command. > > > > > The hashing used for NSEC3 does not need to be so precise. You cannot > > create a false hash as the NSEC3 records themselves are signed. The > > only reason for hashing it to avoid easy zone walking (ie. retrieve all > > names from a zone). You can only make this a bit harder with other > > hashing algorithms at great expense of all. So basically not worth it > > and never done. > > > > > Last but not least: any thoughts on how to perform this algorithm > rollover? > > > > Algoritm rollovers are another thing. This is the algorithm used by the > KSK > > itself to sign the DNSKEY set. The answer is simple. Just update the > > Algorithm of the KSK or ZSK in the kasp.xml and reread this policy file > > using "ods-enforcer policy import". The next rollover will be an > algorithm > > rollover. > > Nice that this is supported in ODS. Makes it easy. > > > > > \Berry > > _______________________________________________ > Opendnssec-user mailing list > [email protected] > https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
_______________________________________________ Opendnssec-user mailing list [email protected] https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
