Hi Joe, > This is not a comment about any deployed version of Unbound, but this kind of > thing seems like a perfect match for the Windows Registry (or the system > keychain on MacOS). Perhaps I'm missing all kinds of battle scars about > dealing with those subsystems as a developer, though.
Yeah, we considered that too. It's pretty much the same as envvars, as far as we're concerned, perhaps neater. No battle scars here in that respect :) Registry and envvars are publicly accessible and that's less than perfect for a DNS root key from a security standpoint. I know, the point of DNSSEC is about remote assaults; I'm just looking what we can get out of the options. > I would strongly advise you not to hard-code the key into anything, ever. > Assuming that any software will be updated regularly has surely proven to be > a bad idea even over the relatively short history of software. If you recall > the last KSK rollover in the root zone (the kind of activity you want to be > able to handle safely and quickly if there's ever a problem) was delayed for > months and months precisely because of a security application that hard-coded > the old key. Thanks, that is a valid remark. I was thinking about tracking updates, not emergencies. > There's a description of how trust anchors are published in RFC 7958. There > are also attempts to provide guidance for bootstrapping validators in > draft-mglt-dnsop-dnssec-validator-requirements (an active document in the > dnsop working group at the IETF) and draft-jabley-dnsop-validator-bootstrap > (an old effort from 2011 that didn't get much traction at the time). All of > this advice could be improved upon, I think, but it's a starting point. Excellent, thank you for the references! -Rick
