[nsd-users] RHEL package?

[Sam Kling]

Hi all,

I had the exact same question about why we could only find old releases of NSD in EPEL. Currently :

- NSD 3.2.18 in EPEL6 (dates back to July 2014)
- No NSD package in EPEL7

Sorry for comparing here over the NSD users mailing-list but just to take an example, each new release of Knot is very quickly packaged. Currently they have the latest release available on EPEL6 and on EPEL7.
And I'm pretty sure that there is not more demand for Knot than there is for NSD...

I really don't want to blame the maintainers of NSD but I think that, when people have to make a choice, how quickly the releases are packaged in the main repositories does count. So for the sake of NSD I hope that the quickness of packaging will improve.

Cheers.





2015-05-21 6:03 GMT+02:00 Paul Wouters <paul at nohats.ca>:

On Thu, 21 May 2015, Anand Buddhdev wrote:

1. Why do you ship an nsd.cron file? It should not be necessary in NSD4,
because it keeps nsd.db up to date by itself.


I understood it does not regularly take the nsd.db and write it out in
the zone files, unless you run "nsdc write"

But the whole autorebuild part of the cron job can be removed I think.

2. I see that you're pointing the default log file location to
/var/log/nsd.log, and the corresponding logrotate snippet also wants to
rotate that file. However, NSD drops privilege from "root" to "nsd", so
it cannot write a log file in /var/log.

It is better to pass the --with-logfile option to configure, and set it
to /var/log/nsd/nsd.log, and create /var/log/nsd writable by nsd. This
is common practice for daemons that drop privilege, so that they can log
properly.


Will do.

3. You're setting --enable-checking, but I think that's only needed for
debugging, and should not be set for a production build.


That has been a bit of a question for me. The description seems to
suggest these are like passert()s which IMHO make the code more secure.
I'm not sure how much of an impact that has on performance...

4. Does anyone use bind8-stats these days? I'd probably want to disable
that option.


will do

5. --enable-nsec3 and --with-ssl are defaults too, and don't need to be
specified.


Will clean up.

6. The chown nsd:nsd of /var/lib/nsd/nsd.db seems unnecessary. What's
the reason for having it there?


I don't remember anymore, but I ran into issues and required it or else
it would be root owned and cause problems.

- chown /var/lib/nsd/nsd.db to the nsd user required for nsd4

I think possibly the old nsd3 has it owned as root, so it is only a
problem during update from nsd3 -> nsd4 ?

7. You're shipping a standard SysV init script, whereas NSD can run just
fine under upstart on CentOS 6. I personally prefer upstart, but I guess
you may want to keep a SysV script for compatibility.


My upstart experience is limited to Ubuntu, and it made me dislike
systemd slightly less. Almost everything on rhel6/centos6 uses sysvinit.

8. In that init script, there's a check for networking at the top, and
then again in the start() function. Seems like a duplicate. Any reason
for this?


The top one is for /etc/sysconfig/nsd for custom options to the daemon,
such as NSD_EXTRA_OPTS=

The one is start is for /etc/sysconfig/network, which is just to check
if the machine has any networking enabled at all via ${NETWORKING}

9. In the init script's stop() section, you're calling "nsd-control
write". This is not necessary. When nsd4 is running with a database, it
reads from nsd.db on startup, and writes changes to it when zones are
updated, so the plain text copy of the zones isn't needed.


I am very old school - I like my zones flat :)

If an admin
really needs plain text zones, s/he can call "nsd-control write" by
hand. Alternatively, if nsd4 is running in the "nodb" mode (where the
option "database" is set to an empty string), then nsd writes out
updated zone files every hour automatically, so that it has plain text
zone files to read from at startup. There's usually no need to write out
zones at exit. However, this has the slight disadvantage of starting up
with possibly slightly stale zones, but in most cases they should be
refresh immediately with XFRs.

I'll leave the choice of whether to write zonefiles or not up to you.


Is there any real impact? Does this cause too much delay for TLD's ?

We could make this an option in /etc/sysconfig/nsd

Paul

_______________________________________________
nsd-users mailing list
nsd-users at NLnetLabs.nl
http://open.nlnetlabs.nl/mailman/listinfo/nsd-users