[nsd-users] NSD 4.12.0rc1 pre-release

[Anand Buddhdev]

Hi Jannik,

What's the rationale behind the "--enable-prometheus-metrics" compile-time
option? If this code were compiled by default, would it do any harm?

The reason I'm asking this is that features that can be enabled/disabled at
compile-time make package distribution complicated. It can result in a
scenario where NSD packages on different operating systems or distributions
have different features. It's especially confusing to an operator reading
the "nsd.conf" man page, noticing the option "metrics-enable", setting it
to "yes" and discovering that it doesn't work, because the feature isn't
compiled in.

Let's take Homebrew as an example. My brew-installed nsd doesn't have RRL
compiled it, so even if I want to test it, I cannot. I have to download the
sources and compile it. Now, my nsd.conf doesn't mention RRL, because the
source of the nsd.conf man page has "rrlstart" and "rrlend" markers, which
probably allow the build process to leave out the RRL sections because the
feature is not compiled in.

But I do not see any such markers for "metrics". The nsd.conf.5 man page
that is generated shows the "metrics-enable" option, but it's not actually
compiled in. It's quite confusing.

Years ago, nsd used to have a compile-time option called
"--enable-root-server". This prevented a standard nsd build from being used
as a root name server, unless one explicitly enabled it when compiling. I
never liked this, and after some discussion, the nsd developers agreed with
me that making it a default was fine.

I think that similarly, it is better if all of nsd's features are just
compiled in, so that a *standard* package just has them all available. The
features should default to "off", naturally. Operators can enable the
features they need in the config file.

Regards,
Anand
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20250416/7e437655/attachment.htm>