Windows location for DNS root key?

Unbound
1

Hi,

We are porting a Linux application to Windows, and this uses Unbound for
DNSSEC security. On Linux, we have a well-defined location for the root
key, namely /etc/unbound/root.key, but on Windows we are less lucky.
What should we use, what do others do; is there a common place, possibly
relative to the library, and will it upgrade automatically?

Thanks,
-Rick

2

Dear Rick,

3

Thanks, Chriztoffer,

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.

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.

Thanks,
-Rick

4

Hi Rick,

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

5

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 :slight_smile:

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

6

On Windows, the root key should probably go in the special folder
Common Application Data. A C/C++ program would use SHGetFolderPath
(https://docs.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetfolderpatha).
A C# program would use CommonApplicationData
(https://docs.microsoft.com/en-us/dotnet/api/system.environment.specialfolder?view=netcore-3.1).

Also see https://stackoverflow.com/questions/22455840/what-can-i-use-as-an-equivalent-for-environment-specialfolder-commonapplicationd.

7

Ah,

On Windows, the root key should probably go in the special folder
Common Application Data.

Ah! That's a long time ago, but a good idea. Thanks!

I do note that there does not seem to be a standard. That is odd...

-Rick