Hello all, newbie here planning to deploy NSD soon for my company. I’ve looking for NSD packages for RHEL 5/6 and just found some old ones (3.x) at http://rpm.pbone.net. Does anyone know why RedHhat doesn’t officially support NSD? does any third party provide an updated package for a RHEL distro?
Thanks in advance for comments.
LU
http://awel.domblogger.net/7/misc/src/repoview/nsd.html
That is my src.rpm for CentOS 7 - which is really just a Fedora src.rpm
It doesn't properly start when the server boots, which may be why it isn't in EPEL - I use a cron job once a minute to start it if it isn't running.
And I need to migrate to nsd4
But that works really well for me on CentOS 7 other than not starting at system boot even when configured to.
This is the spec I use to build NSD4 for CentOS 6.
Hi Michael,
http://awel.domblogger.net/7/misc/src/repoview/nsd.html
That is my src.rpm for CentOS 7 - which is really just a Fedora src.rpm
It doesn't properly start when the server boots, which may be why it
isn't in EPEL - I use a cron job once a minute to start it if it isn't
running.
NSD3 is very hard to run properly under supervisors such as upstart or
systemd.
And I need to migrate to nsd4
NSD4 has many improvements, including a stable master process, so that
you can run it easily under a supervisor.
I have a SPEC file for NSD4, but it is heavily tailored for our
environment, so it's not suitable for release. However, I'd be happy to
adjust it for EPEL or even Fedora.
Regards,
Anand
Hi Tom,
Your spec is somewhat outdated. For example, in NSD4, there is no need
for an hourly cron to patch the nsd.db file.
I also notice that you're starting NSD with a traditional SysV init
script. While that works on CentOS 6, my personal preference is to run
everything under a supervisor if possible, so in our spec, I install an
upstart script to run nsd. However, I'm probably in the minority here,
in running my daemons under upstart on CentOS 6.
Regards,
Anand
I have been working on shipping nsd4 in EPEL6 and EPEL7, but no one gave
me feedback: https://twitter.com/letoams/status/586764009162088448
An EPEL6 build of nsd4.1.1 that I'm running myself on ns0.nohats.ca can be
found at: http://koji.fedoraproject.org/koji/taskinfo?taskID=9461112
I was hoping on some feedback before pushing such a big change into
EPEL6.
Paul
Hi Paul,
I have been working on shipping nsd4 in EPEL6 and EPEL7, but no one gave
me feedback: https://twitter.com/letoams/status/586764009162088448
I must have missed this. I will review this soon, and give you feedback.
Regards,
Anand
Unfortunately I’m still running RHEL5 here, will see what I can do to upgrade to a newer version using some of the specs files provided, but actually I’m not a big fan to compile software for production servers. I hope to find NSD supported by RH in the near future, it would be great to upgrade/patch by simply running ‘yum update’.
Thanks all for your responses.
Regards, LU
Hi Paul,
I was just looking at the SPEC file of NSD 4.1.1 in Fedora. I have
noticed some things, and would like to ask you about them:
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.
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.
3. You're setting --enable-checking, but I think that's only needed for
debugging, and should not be set for a production build.
4. Does anyone use bind8-stats these days? I'd probably want to disable
that option.
5. --enable-nsec3 and --with-ssl are defaults too, and don't need to be
specified.
6. The chown nsd:nsd of /var/lib/nsd/nsd.db seems unnecessary. What's
the reason for having it there?
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.
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?
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. 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.
Regards,
Anand
Not only for NSD, but NLnetLabs Unbound also usually have old versions you don’t want to run available at distributions repositories. Manual compiling recommended, even if you just use your distribution, make a package and then replicate.
Rubens
Does anyone know why RedHhat doesn't officially support NSD?
[with my red hat on]
Not sufficient customer demand. The only way to get a package into RHEL
is for paying customers to want it.
I (co?)maintain the package in Fedora and EPEL.
does any third party provide
an updated package for a RHEL distro?
Yes, it is in epel, see https://fedoraproject.org/wiki/EPEL/FAQ
Not only for NSD, but NLnetLabs Unbound also usually have old versions you don't want to run available at distributions repositories.
Manual compiling recommended, even if you just use your distribution, make a package and then replicate.
Note that unbound is in RHEL7. It is not in RHEL6 but it is in EPEL6.
We try to keep current with these packages, but it is harder to jump
major versions. If there is very valid reason for, we will still rebase
it during a release.
Paul
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
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.
The epel7 branch has been requested, but I focused first on nsd in
EPEL6 since most people running production servers (myself included)
do so on RHEL6. I've gotten some feedback now, although I'm still
a little uneasy at not having had reports of success on nsd3 -> nsd4
updates with the package.
Note that this is sort of against the guidelines of epel (which is not
supposed to be newer than fedora). But I really wanted to focus on the
nsd major revision migration before also throwing in the systemd
changes. I'll push out the fedora update this weekend, but note that
I do not know anyone actually running nsd seriously on fedora.
I'll incorporate the changes from the feedback received over the last
few days this weekend. I would still like to get more feedback on the
nsd3 -> nsd4 upgrade with this new package for EPEL6. I've only tested
this on my own server so far.
Paul
I'm out of town at the moment but I promise to give CentOS 7 feedback as soon as I am back. Unfortunately where I am at right now, ssh doesn't work - I can log into my servers (custom high port) but connection gets dropped with 5 seconds, really frustrating.
I am currently running 1 master and 2 slaves on CentOS 7 using a rebuild of the Fedora 3.x src.rpm
Creating a custom build of NSD 4 is something I have been toying with, I'm pretty good with RPM, but I much prefer EPEL packages for the obvious maintenance issues, it just makes it easier.
I should be back home on Thursday.
Thank you for doing this, this is very important to a new service I'm starting (providing DNSSEC DNS services to small business via web interface where they don't have to worry about key rollovers etc.)