Hi Rick, On 11 May 2020, at 10:37, Rick van Rein via Unbound-users <[email protected]> wrote:
> We are using an MSYS2 build, so no GUI install, but your suggestion comes > down to "C:\Program Files\Unbound\root.key" if I understand you correctly. > This is assuming a system-central install of Unbound, whereas we include the > library from a sort-of ports tree. Still, it's helpful to know what > otherwise would be the location. 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. > We're also considering to hard-code the key into the application; this makes > sense for a security application, which needs to track updates anyway. 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. 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. Joe
signature.asc
Description: Message signed with OpenPGP
