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
440 stars 102 forks source link

Add zones without nsd-control #323

Closed orlitzky closed 1 week ago

orlitzky commented 4 months ago

If I change one of my zones, I can reload it using systemctl reload nsd. This makes use of systemd's ExecReload, which can be overridden but typically just sends SIGHUP to the daemon's PID. This is especially nice because the unprivileged nsd user is allowed to send SIGHUP to his own process, so changing zones does not require root.

If I add a zone, however, I have to change nsd.conf or one of its include files, and I've noticed that SIGHUP will not cause nsd to "reload" the new zone. Instead, nsd-control refers to that as "reconfig". If nsd-control is not enabled, a full restart of the daemon is therefore required to add a zone, and that requires root.

Is there some way around this? The description of the systemd feature says that it "triggers a configuration reload," and it would be nice if there was a way to force a reconfig instead of just a zone reload using that mechanism. Maybe a reconfig could be triggered with SIGUSR2?

In short, the problem I'm trying to solve is to be able to add new zones locally without root privileges and without nsd-control.

k0ekk0ek commented 4 months ago

Hi @orlitzky! I'm sorry this slipped through. I'll take a look at this next week.

orlitzky commented 4 months ago

No problem, it's not urgent, thank you.

We don't add zones that often so I've been logging in as root and restarting the daemon myself as necessary. If the answer turns out to be "use nsd-control" then I can live with that too :)

k0ekk0ek commented 4 months ago

Hi @orlitzky! Detecting new zones on SIGHUP seems like desired behavior. We'll change the behavior to do that, shouldn't be too hard to do, but I won't get around to it immediately. Thanks for the suggestion :+1:

orlitzky commented 4 months ago

Sounds good, thank you.

k0ekk0ek commented 2 weeks ago

@orlitzky, #373 should add the functionality described on this ticket.

anandb-ripencc commented 1 week ago

Reload zones, patterns and tsig keys, and re-open log file on SIGHUP is a very useful addition to NSD, and should have been there much earlier, IMHO. Is there any reason it's not just a default, instead of yet another option in nsd.conf that one has to enable?

Additionally, the change in the nsd man page isn't very clear about all the things affected by SIGHUP. It now says "Reopen logfile (assists rotation) and optionally update TSIG keys and zones.". However, a SIGHUP now does:

  1. Updates patterns
  2. Updates TSIG keys
  3. Updates zone definitions
  4. Examines mtimes of existing primary zones and reload them
  5. Reopens the log file (to help with log rotation)

I think all the 5 consequences of a SIGHUP should be clearly documented in the nsd man page.

Additionally, is the effect of nsd-control reload the same as a SIGHUP? Is the reconfig command of nsd-control even needed now?

I urge you to examine this change more carefully, and unify the way reload/reconfig is done in NSD, to avoid confusion and duplication.

k0ekk0ek commented 1 week ago

Hi @anandb-ripencc!

Is there any reason it's not just a default, instead of yet another option in nsd.conf that one has to enable?

It's a change in behavior. It makes sense to make it the default, but we can do that in a later release (at least a minor, I've created #374).

I left it very broad on purpose thinking that adding too much detail doesn't help the user either? My reasoning was the user would check nsd.conf(5), but we can change it if you insist. Suggestions?

Additionally, is the effect of nsd-control reload the same as a SIGHUP?

It is not the same. nsd-control repattern allows you to reload the configuration remote but doesn't require a SIGHUP and does not re-examine zone files.

anandb-ripencc commented 1 week ago

Hi Jeroen. I've put all my detailed thoughts about this, and related issues, in the comments of #374. You can leave this as closed, and we can continue the discussion that that issue.