search

NLnetLabs / nsd

The NLnet Labs Name Server Daemon (NSD) is an authoritative, RFC compliant DNS nameserver.
https://nlnetlabs.nl/nsd
BSD 3-Clause "New" or "Revised" License
444 stars 101 forks source link

Default location of "cookie-secret-file" #196

Open anandb-ripencc opened 2 years ago

anandb-ripencc commented 2 years ago

The nsd.conf man page says that the default location of the cookie secret file is /etc/nsd/nsd_cookiesecrets.txt. However, if one tries to add a cookie using nsd-control, this is what happens:

# nsd-control add_cookie_secret ae44cc3c8ceaaa64f5811e9a55442ab6
unable to open cookie secret file /etc/nsd/nsd_cookiesecrets.txt: Permission deniederror: writing to cookie secret file: "/etc/nsd/nsd_cookiesecrets.txt"

The reason for this is that /etc/nsd is usually not writable by anyone other than "root", but the NSD server normally runs as a non-root user. This is generally true of most daemons on unix-like systems. If a running daemon wants to create some kind of state file, such a file should normally go into a location such as /var/lib/nsd, which is writeble by the "nsd" user. In fact, all of NSD's other state files (nsd.db, xfrd.state, dynamically added zone list, etc) go here. So I find it surprising that the dynamic cookie secret file's default location is /etc/nsd. It does not follow best practices for unix-like systems.

I then tried to see if I could change this default at compile time, but there's no configure option for this either (whereas there are options for specifying default locations for the log file, database file, state file, zone list file, etc). I consider this a bug, and I think that you should change the default to point to the same place as NSD's other run-time state files.

anandb-ripencc commented 3 weeks ago

This issue is still open, and a recent discussion of cookies and run-time reconfiguration brought me back here. While this bug needs to be fixed, I also feel like cookie secrets are something that should be modifiable at run-time with a reconfig. BIND makes this very easy, by allowing multiple secrets to be defined. The first is used as the "active" one, while all others after it are used only for verification. Rolling the secret is made easy, by just changing the order of the secret in named.conf and reloading the configuration.

For NSD, instead of using a cookie file, I can envision having secrets in nsd.conf, similar to BIND, with the first one used as the active secret. Since secret is already an option, you could introduce staging-secret as an additional option, to specify one or more incoming secrets. The operator can just swap secret and staging-secret around, and reload the configuration.

This is of course dependent on the ability to reconfigure NSD on the fly, as I have suggested in #374.

wtoorop commented 3 weeks ago

Hi @anandb-ripencc , Completely agree. The choice of location for the file was obviously a mistake (by me). I'll create a fix shortly. I think we can even automatically move (or copy) the file to the new location when the option didn't have a value in the config file and a file in the old location is detected.

I also think the staging-secret: config option is a good idea.