nlnetlabs/nsd

The NLnet Labs Name Server Daemon (NSD) is an authoritative, RFC compliant DNS nameserver.

NSD

The NLnet Labs Name Server Daemon (NSD) is an authoritative DNS name server. It has been developed for operations in environments where speed, reliability, stability and security are of high importance. If you have any feedback, we would love to hear from you. Don’t hesitate to create an issue on Github or post a message on the NSD mailing list. You can learn more about NSD by reading our documentation.

Building

Make sure you have the following installed:

• C toolchain (the set of tools to compile C such as a compiler, linker, and assembler)
• OpenSSL, with its include files (usually these are included in the "dev" version of the library)
• libevent, with its include files (usually these are included in the "dev" version of the library)
• flex
• bison

When building from Git, the configure script and simdzone sources are missing, use the following commands to get started (note that the configure script and sources are included in release tarballs and do not need to be generated/downloaded):

$ git submodule update --init
$ autoreconf -fi

autoreconf should install the required auxiliary files (e.g. config.sub and config.guess). Older versions of autoreconf may not do so, try running libtoolize -fi -c first in that case.

Compile and install using:

$ ./configure && make && make install

NSD configuration

The configuration options for NSD are described in the man pages, which are installed (use man nsd.conf) and are available on the NSD documentation page.

An example configuration file is located in nsd.conf.sample.

nsd's Issues

Feature Request: RFC2136 aka DNS Update support for nsd

Since nsd is an authoritative DNS intended as a replacement for ISC bind, would it be possible that at some point it can gain the Dynamic DNS facility that bind supports and which is specified by RFC2136?

Please note that I'm not asking for unbound to gain this facility, despite the fact that it is local-authoritative - as it seems pretty clear that it will not be added.

NetBSD and util.c:267:24: warning: implicit declaration of function 'reallocarray'

Hi Everyone, @wcawijngaards,

I'm testing nsd master on NetBSD 8.1. One dirty compile shown below. Self tests are OK.

The annoying thing about this report is, manually defining _OPENBSD_SOURCE and manually including <stdlib.h> early does not clear the issue. It is as if the NetBSD man pages are wrong.

gcc -I. -I/usr/pkg/include -g -O2 -flto -c ./util.c
./util.c: In function 'xmallocarray':
./util.c:267:24: warning: implicit declaration of function 'reallocarray' [-Wimplicit-function-declaration]
         void *result = reallocarray(NULL, num, size);
                        ^
./util.c:267:24: warning: initialization makes pointer from integer without a cast [-Wint-conversion]

Sorry for the pettiness. Nsd is just about clean on all platforms, so this sticks out like a sore thumb.

---

According to the NetBSD reallocarray(3) man page:

#define _OPENBSD_SOURCE
#include <stdlib.h>

void *
reallocarray(void *ptr, size_t nmemb, size_t size);

But the configure test result is not used (or HAVE_REALLOCARRAY is not used) in util.c:

$ grep -IR reallocarray util.c
        void *result = reallocarray(NULL, num, size);
                log_msg(LOG_ERR, "reallocarray failed: %s", strerror(errno));

Also see this note under HISTORY (when in Rome do as the Romans do...):

The reallocarray() function first appeared in OpenBSD 5.6.
reallocarray() was redesigned in NetBSD 8 as reallocarr(3).  For compati-
bility reasons it's available since NetBSD 8 in the _OPENBSD_SOURCE
namespace.

And:

This function is provided for source compatibility with OpenBSD and its
use is discouraged in preference to reallocarr(3).

---

And this may help:

$ gcc -dM -E - </dev/null | grep -i -E 'linux|bsd|gnu|i*86|x86|amd' | sort
#define __GNUC_MINOR__ 5
#define __GNUC_PATCHLEVEL__ 0
#define __GNUC_STDC_INLINE__ 1
#define __GNUC__ 5
#define __NetBSD__ 1
#define __amd64 1
#define __amd64__ 1
#define __x86_64 1
#define __x86_64__ 1

error: 'fd_set' undeclared (first use in this function)

Hi Everyone,

I working from nsd master on OpenBSD 6.6. Bootstrap and configure go well, but compile has a hiccup:

$ make -k
...
gcc  -I. -fasynchronous-unwind-tables -fexceptions -fstack-protector-strong -Wer
ror=implicit-function-declaration -fdata-sections -ffunction-sections -fPIC  -Wa
,--noexecstack -g -O2 -c ./popen3.c
./popen3.c: In function 'popen3':
./popen3.c:106: error: 'fd_set' undeclared (first use in this function)
./popen3.c:106: error: (Each undeclared identifier is reported only once
./popen3.c:106: error: for each function it appears in.)
./popen3.c:106: error: expected ';' before 'rfds'
./popen3.c:111: warning: implicit declaration of function 'FD_ZERO'
./popen3.c:111: error: 'rfds' undeclared (first use in this function)
./popen3.c:112: warning: implicit declaration of function 'FD_SET'
./popen3.c:113: warning: implicit declaration of function 'select'

I believe this is the OpenBSD doc of interest: select(2) - OpenBSD manual pages. It looks like OpenBSD puts the declaration in <sys/select.h>.

Another man page of interest is the Linux man page. Linux and libc put the declarations in either <sys/types.h> or <sys/select.h>.

Related, the source file also uses ssize_t. I believe that is defined in <sys/types.h>.

nsd-4.2.2 on macOS 10:

> uname -a
Darwin local 18.7.0 Darwin Kernel Version 18.7.0: Sat Oct 12 00:02:19 PDT 2019; root:xnu-4903.278.12~1/RELEASE_X86_64 x86_64

> cd /opt/src/nsd-4.2.2
...
>./configure
...
checking for fcntl.h... no
checking limits.h usability... no
checking limits.h presence... yes
configure: WARNING: limits.h: present but cannot be compiled
configure: WARNING: limits.h:     check for missing prerequisite headers?
configure: WARNING: limits.h: see the Autoconf documentation
configure: WARNING: limits.h:     section "Present But Cannot Be Compiled"
configure: WARNING: limits.h: proceeding with the compiler's result
configure: WARNING:     ## ------------------------------------ ##
configure: WARNING:     ## Report this to [email protected] ##
configure: WARNING:     ## ------------------------------------ ##
checking for limits.h... no
checking netinet/in.h usability... no
checking netinet/in.h presence... no
checking for netinet/in.h... no
checking netinet/tcp.h usability... no
checking netinet/tcp.h presence... no
checking for netinet/tcp.h... no
checking stddef.h usability... no
checking stddef.h presence... yes
configure: WARNING: stddef.h: present but cannot be compiled
configure: WARNING: stddef.h:     check for missing prerequisite headers?
configure: WARNING: stddef.h: see the Autoconf documentation
configure: WARNING: stddef.h:     section "Present But Cannot Be Compiled"
configure: WARNING: stddef.h: proceeding with the compiler's result
configure: WARNING:     ## ------------------------------------ ##
configure: WARNING:     ## Report this to [email protected] ##
configure: WARNING:     ## ------------------------------------ ##
checking for stddef.h... no
checking sys/param.h usability... no
checking sys/param.h presence... no
checking for sys/param.h... no
checking sys/socket.h usability... no
checking sys/socket.h presence... no
checking for sys/socket.h... no
checking sys/un.h usability... no
checking sys/un.h presence... no
checking for sys/un.h... no
checking syslog.h usability... no
checking syslog.h presence... no
checking for syslog.h... no
checking for unistd.h... (cached) yes
checking sys/select.h usability... no
checking sys/select.h presence... no
checking for sys/select.h... no
checking stdarg.h usability... no
checking stdarg.h presence... yes
configure: WARNING: stdarg.h: present but cannot be compiled
configure: WARNING: stdarg.h:     check for missing prerequisite headers?
configure: WARNING: stdarg.h: see the Autoconf documentation
configure: WARNING: stdarg.h:     section "Present But Cannot Be Compiled"
configure: WARNING: stdarg.h: proceeding with the compiler's result
configure: WARNING:     ## ------------------------------------ ##
configure: WARNING:     ## Report this to [email protected] ##
configure: WARNING:     ## ------------------------------------ ##
checking for stdarg.h... no
checking for stdint.h... (cached) yes
checking netdb.h usability... no
checking netdb.h presence... no
checking for netdb.h... no
checking sys/bitypes.h usability... no
...

https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Present-But-Cannot-Be-Compiled.html

GNU HURD and cpuset.h:62:16: error: unknown type name ‘cpuid_t’

Hi Everyone,

I'm testing nsd master on GNU HURD. The HURD image is dated JAN 2020, and is fully patched. HURD is a GNU Linux operating system with a personality. It is also i386, not x86_64.

Bootstrap and configure go well. Below is the output of make. Several files show the same issue.

$ make
gcc -I. -I/usr/local/include -g -O2 -flto -c answer.c
In file included from config.h:894,
                 from answer.c:10:
compat/cpuset.h:62:16: error: unknown type name ‘cpuid_t’; did you mean ‘pid_t’?
   62 | int cpuset_set(cpuid_t cpu, cpuset_t *set);
      |                ^~~~~~~
      |                pid_t
compat/cpuset.h:66:16: error: unknown type name ‘cpuid_t’; did you mean ‘pid_t’?
   66 | int cpuset_clr(cpuid_t cpu, cpuset_t *set);
      |                ^~~~~~~
      |                pid_t
compat/cpuset.h:70:18: error: unknown type name ‘cpuid_t’; did you mean ‘pid_t’?
   70 | int cpuset_isset(cpuid_t cpu, const cpuset_t *set);
      |                  ^~~~~~~
      |                  pid_t
Makefile:89: recipe for target 'answer.o' failed
make: *** [answer.o] Error 1

According to the CPU_SET(3) man page:

   #define _GNU_SOURCE             /* See feature_test_macros(7) */
   #include <sched.h>

These may also be helpful.

$ gcc -dM -E - </dev/null | sort | grep -i -E 'linux|hurd|gnu|i*86|amd'
#define __GNU__ 1
#define __GNUC__ 9
#define __GNUC_MINOR__ 3
#define __GNUC_PATCHLEVEL__ 0
#define __GNUC_STDC_INLINE__ 1
#define __gnu_hurd__ 1
#define __i386 1
#define __i386__ 1
#define i386 1
#define __i586 1
#define __i586__ 1

It looks like this clears the issue. I'm not sure how you feel to reaching into the header and using a private typedef like __cpu_mask. (It works for me :)

$ git diff
diff --git a/compat/cpuset.h b/compat/cpuset.h
index c7cd2dc1..d51ce3f9 100644
--- a/compat/cpuset.h
+++ b/compat/cpuset.h
@@ -44,6 +44,9 @@ typedef int cpuid_t;
 #ifdef __FreeBSD__
 typedef size_t cpuid_t;
 #endif
+#ifdef __gnu_hurd__
+typedef __cpu_mask cpuid_t;
+#endif
 #endif

Willingness to support non-forking readiness notification for s6 and other service supervisors?

Hello,

I have implemented a non-forking service readiness notification that is compatible with the s6 service supervision suite as well as my own personal fork of Upstart.

Would you accept a patch to support this protocol, which would:

• accept a CLI argument telling nsd when to use the mechanism
• grab an fd number from the environment and write a newline to it
• close the fd and unset the environment variable

The patch would look largely similar to swaywm/swaylock#42 or apple/cups#5507.

More information on the mechanism can be found at https://gitlab.com/chinstrap/ready

Regards,
Cameron Nemo

periodic crashes when parsing config

I've noticed some crashes in nsd apparently when parsing the config:

[1245276.933679] traps: nsd[22786] general protection fault ip:55ee2fdfc95b sp:7ffd63c299d8 error:0 in nsd[55ee2fde1000+5e000]
[1263776.965752] traps: nsd[9060] general protection fault ip:55ee2fdfc95b sp:7ffd63c299d8 error:0 in nsd[55ee2fde1000+5e000]
[1319575.155940] traps: nsd[20859] general protection fault ip:55ee2fdfc95b sp:7ffd63c299d8 error:0 in nsd[55ee2fde1000+5e000]
[1365798.607058] traps: nsd[23810] general protection fault ip:55ee2fdfc95b sp:7ffd63c299d8 error:0 in nsd[55ee2fde1000+5e000]

When looking at what is going on it seems to in the c_parse function:

(gdb) info line *0xc95b
Line 1654 of "configparser.c" starts at address 0xc93b <c_parse+203> and ends at 0xc95d <c_parse+237>.
(gdb) x/i 0xc95b
   0xc95b <c_parse+235>:	add    %al,(%rax)

I don't seem to have core files available for this, and it doesn't seem to crash in a way that takes the daemon down. The reconfig command is issued every 5 minutes with a configuration file parsed from the database.

I can share the main config file and the include zone file as well in private.

make (dist)clean does not delete config.h

./configure creates config.h, but neither "make clean”, nore “make distclean” deletes it. The GNU coding standards convention is to delete with “make distclean” whatever “./configure” creates. I use nsd 4.2.3.

GNU coding standards extract: https://www.gnu.org/prep/standards/html_node/Standard-Targets.html#Standard-Targets , see “distclean”.

The reproducing procedure is:

I download and unpack nsd-4.2.3. Then I go in the nsd-4.2.3 forder, call ./configure . Then I call ”make disclean; make clean; mkdir build; cd build ; ../configure --enable-mmap --enable-systemd --enable-recvmmsg --with-configdir=/etc/nsd --with-user=nsd ” . This fail because ../config.h. exists and deleting config.h, and re-invoking build/configure ... emits again that ../config.h exists.

So if I run ./configure in the in-source-tree, before doing out-of-source (VPATH) build, “make distclean” shall revert all side-effects of ./configure and let me later perfom VPATH build.

NSD 4.3.1 - make test fails

Just downloaded last 4.3.1 tarball from your site.
The host is an Ubuntu server 18.04, and I already built successfully nsd 4.2.4 on this server.
./configure -> ok
make -> ok
make test -> returns me this error:
make: *** No rule to make target 'tpkg/cutest/cutest_dname.c', needed by 'cutest_dname.o'. Stop.

And yes, I'm sure I run make test

Let me know if you need additional info

GNU HURD and util.c:1190: warning: sched_setaffinity is not implemented and will always fail

Hi Everyone, @wcawijngaards,

Here's the last issue report for HURD. HURD needs a patch for _GNU_SOURCE and <sched.h>. Then it needs a custom AC_COMPILE_IFELSE test. That's attached in the PR.

Now, when linking nsd, we get this message:

gcc -g -O2 -flto -L/usr/local/lib -o nsd-checkconf answer.o axfr.o buffer.o conf
iglexer.o configparser.o dname.o dns.o edns.o iterated_hash.o lookup3.o namedb.o
 nsec3.o options.o packet.o query.o rbtree.o radtree.o rdata.o region-allocator.
o rrl.o tsig.o tsig-openssl.o udb.o udbradtree.o udbzone.o util.o bitset.o popen
3.o nsd-checkconf.o cpuset.o strlcat.o strlcpy.o b64_pton.o b64_ntop.o setprocti
tle.o -lcrypto -ldl -levent
/usr/bin/ld: /tmp/nsd.HEkDrr.ltrans3.ltrans.o: in function `set_cpu_affinity':
/home/nsd/util.c:1190: warning: sched_setaffinity is not implemented and will always fail

According to Success in building x86info under GNU/Hurd on the HURD mailing list, this is expected because mach kernels are single core:

Yes, that's not implemented yet on GNU/Hurd, since the mach is
mono-processor for now. For the same reason it's actually not a problem
at all, x86info only needs setaffinity on multi-processor boxes.

The idea is, you have lots of little servers running around and communicating and passing messages rather than a big, monolithic kernel.

Moving forward, cutest succeeds:

jwalton@hurd-x86:~/nsd$ ./cutest 
srandom(1584675682)
....................................................
OK (52 tests)
SKIP (0 tests)

At this point, I know Linux, DragonFly, FreeBSD, NetBSD, OpenBSD and HURD pass the self tests.

util.c compiles on Solaris, but not much more. Lex and Yacc are too anemic, and there are no replacements available in /usr/gnu/bin. In practice Solaris is not supported.

cutest_bitset.c:22: error: 'for' loop initial declaration used outside C99 mode

Hi Everyone,

I working from nsd master on OpenBSD 6.6. Bootstrap and configure go well: make check has a small hiccup:

gcc -I. -g -O2 -c ./tpkg/cutest/cutest_util.c
gcc -I. -g -O2 -c ./tpkg/cutest/cutest_bitset.c
./tpkg/cutest/cutest_bitset.c: In function 'bitset_set_unset_test':
./tpkg/cutest/cutest_bitset.c:22: error: 'for' loop initial declaration used outside C99 mode
./tpkg/cutest/cutest_bitset.c:30: error: redefinition of 'bit'
./tpkg/cutest/cutest_bitset.c:22: error: previous definition of 'bit' was here
./tpkg/cutest/cutest_bitset.c:30: error: 'for' loop initial declaration used outside C99 mode
./tpkg/cutest/cutest_bitset.c:34: error: redefinition of 'bit'
./tpkg/cutest/cutest_bitset.c:30: error: previous definition of 'bit' was here
./tpkg/cutest/cutest_bitset.c:34: error: 'for' loop initial declaration used outside C99 mode
./tpkg/cutest/cutest_bitset.c:38: error: redefinition of 'bit'
./tpkg/cutest/cutest_bitset.c:34: error: previous definition of 'bit' was here
./tpkg/cutest/cutest_bitset.c:38: error: 'for' loop initial declaration used outside C99 mode
./tpkg/cutest/cutest_bitset.c: In function 'bitset_or_even_odd':
./tpkg/cutest/cutest_bitset.c:78: error: 'for' loop initial declaration used outside C99 mode
./tpkg/cutest/cutest_bitset.c:87: error: redefinition of 'bit'
./tpkg/cutest/cutest_bitset.c:78: error: previous definition of 'bit' was here
./tpkg/cutest/cutest_bitset.c:87: error: 'for' loop initial declaration used outside C99 mode
./tpkg/cutest/cutest_bitset.c:95: error: redefinition of 'bit'
./tpkg/cutest/cutest_bitset.c:87: error: previous definition of 'bit' was here
./tpkg/cutest/cutest_bitset.c:95: error: 'for' loop initial declaration used outside C99 mode
./tpkg/cutest/cutest_bitset.c: In function 'bitset_or_even_even':
./tpkg/cutest/cutest_bitset.c:126: error: 'for' loop initial declaration used outside C99 mode
./tpkg/cutest/cutest_bitset.c:133: error: redefinition of 'bit'
./tpkg/cutest/cutest_bitset.c:126: error: previous definition of 'bit' was here
./tpkg/cutest/cutest_bitset.c:133: error: 'for' loop initial declaration used outside C99 mode
./tpkg/cutest/cutest_bitset.c:141: error: redefinition of 'bit'
./tpkg/cutest/cutest_bitset.c:133: error: previous definition of 'bit' was here
./tpkg/cutest/cutest_bitset.c:141: error: 'for' loop initial declaration used outside C99 mode

EDNS unknown version: query not in response

Hi,
I am currently testing the response of NSD (v4.1.26) to EDNS OPT confirmability (http://ednscomp.isc.org/ednscomp/). I am looking in particular at the confirmation of a request with a bad EDNS version like:
dig +edns=1 soa zone @server
If I look at the network response, I observe that in this case, the response from NSD does not contain the initial request. I just get a response containing an additional OPT records.
If I make the request by specifying edns=0, then NSD responds correctly by copying the initial request well in its response.
I tested with Bind and Unbound, they behave well with edns=1, they respond well by copying the initial request in their response.
In what I observe, only NSD does not copy the initial request in its response when edns=1.
This is problematic for me because my NSD is behind a dnsdist and it considers that the answer is "non compliant" and therefore does not transmit it to the client who made the request.
I do not know if dnsdist is right to consider the response as "not compliant" because it does not contain the initial request but since NSD is the only one in my tests to behave like this, I wonder if there is is not a problem.
Thanks

Redundant records in the response

Hi,
I have noticed a regression in NSD 4.2.3. There are redundant records in the authority and additional sections in responses like:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6299
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ns2.zone10.			IN	AAAA

;; ANSWER SECTION:
ns2.zone10.		3600	IN	AAAA	2001:db8::2

;; AUTHORITY SECTION:
zone10.			3600	IN	NS	ns1.zone10.
zone10.			3600	IN	NS	ns2.zone10.

;; ADDITIONAL SECTION:
ns1.zone10.		3600	IN	A	192.0.2.1
ns2.zone10.		3600	IN	A	192.0.2.2
ns1.zone10.		3600	IN	AAAA	2001:db8::1

Relevant configuration:

minimal-responses: yes

Any tips for compiling on linux

Hi NetLabs,

I'm trying to build a version with as few dependencies as pos for LXC containers, (esp systemd)

Any tips for building in Linux?

So far I have

apt install flex bison
$ ./configure \
   --enable-systemd=no \
   --enable-ipv6=no \
   --enable-dnstap=no \
   --enable-bind8-stats=no \
   --enable-zone-stats=no \
   --enable-nsec3=no
make

This gives me

ldd nsd
	linux-vdso.so.1 (0x00007ffc9a71d000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb6524c9000)
	libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007fb652437000)
	libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007fb652162000)
	libevent-2.1.so.6 => /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6 (0x00007fb651f11000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fb652796000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb651eee000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb651ee8000)

this is good enough, but wondering if there is anything I can do to get rid of SSL deps since I'm not using DNSSEC.

Drop sparse TSIG signing support in NSD

With the new RFC2845bis draft, sparse TSIG signing is deprecated. For backward compatibility, receiving sparse TSIG responses still needs to be supported.

From draft-ietf-dnsop-rfc2845bis-06, Section 5.3.1:

The TSIG MUST be included on all DNS messages in the response. For backward compatibility, a client which receives DNS messages and verifies TSIG MUST accept up to 99 intermediary messages without a TSIG.

If draft-ietf-dnsop-rfc2845bis will be an RFC, consider dropping sparse TSIG signing support in NSD.

-- Benno

NSD v 4.2.2 - fork failed: Cannot allocate memory

After OS upgrade (centos 7.7) and NSD upgrade (v4.1.24-2 to v.4.2.2-1) we encounter issues with NSD on our authoritative nameserver:
nsd[5346]: warning: server 16222 died unexpectedly, restarting
nsd[5346]: error: fork failed: Cannot allocate memory
nsd[5346]: warning: process 16222 terminated with status 9

kernel: nsd invoked oom-killer: gfp_mask=0x200da, order=0, oom_score_adj=0
kernel: nsd cpuset=/ mems_allowed=0-1
kernel: CPU: 23 PID: 11340 Comm: nsd Not tainted 3.10.0-1062.4.1.el7.x86_64 #1

The NSD package installed is from the EPEL repository.

The EPEL NSD SPEC file list the options used for v4.2.2-1:
--enable-recvmmsg --enable-packed --enable-memclean --enable-zone-stats

I wonder if either of these options (--enable-packed --enable-memclean) could be the cause of our issue ?

stats: include tls related query stats

for TCP queries, it would be useful to see how many were serviced either by the listening port or served via DoTLS

Option to force-reload a zone

Please provide a command with which all zones can be forcefully reinitialised from disk, short of restarting nsd. I.e. nsd-control force-reload [zone], which skips the "has file been modified" check.

Solaris and lex defines yy_current_buffer... lex: illegal option -- i

Hi Everyone,

I'm testing nsd master on Solaris 11.3 i86pc, fully patched. Solaris is a multiarch machine out of the box.

The lex test in configure.ac is producing some noise:

checking for flex... no
checking for lex... lex
checking lex output file root... lex.yy
checking lex library... -ll
checking whether yytext is a pointer... no
checking for bison... no
checking for byacc... no
checking if lex defines yy_current_buffer... lex: illegal option -- i
Usage: lex [-ewctvnVY] [-Q(y/n)] [file]
no

Oracle has good docs. You can find the man page at lex(1) man page.

DragonFly and cpuset.h:62:16: error: unknown type name 'cpuid_t'

Hi Everyone,

I'm testing nsd master on DragonFly 5.6 x86_64, fully patched. DragonFly is a BSD variant.

Bootstrap and configure go well. Below is the output of make. Several files show the same issue.

 int cpuset_set(cpuid_t cpu, cpuset_t *set);
                ^~~~~~~
                uid_t
./compat/cpuset.h:66:16: error: unknown type name 'cpuid_t'; did you mean 'uid_t'?
 int cpuset_clr(cpuid_t cpu, cpuset_t *set);
                ^~~~~~~
                uid_t
./compat/cpuset.h:70:18: error: unknown type name 'cpuid_t'; did you mean 'uid_t'?
 int cpuset_isset(cpuid_t cpu, const cpuset_t *set);
                  ^~~~~~~
                  uid_t
*** Error code 1

It looks like DragonFly has <sched.h>.

% grep -IR cpu_set_t /usr/include
/usr/include/sched.h:typedef	cpumask_t		cpu_set_t;
...

And cpumask_t is declared in /usr/include/cpu/types.h:

/*
 * cpumask_t - a mask representing a set of cpus and supporting routines.
 *
 * WARNING! It is recommended that this mask NOT be made variably-sized
 *	    because it affects a huge number of system structures.  However,
 *	    kernel code (non-module) can be optimized to not operate on the
 *	    whole mask.
 */

#define _CPUMASK_ELEMENTS	4	/* tested by assembly for #error */

typedef struct {
	__uint64_t      ary[4];
} cpumask_t;

This may help.

% gcc -dM -E - < /dev/null | sort | grep -i -E 'linux|bsd|gnu|linux|dragon|i*86|amd'
#define __DragonFly__ 1
#define __GNUC_MINOR__ 3
#define __GNUC_PATCHLEVEL__ 0
#define __GNUC_STDC_INLINE__ 1
#define __GNUC__ 8
#define __VERSION__ "8.3 [DragonFly] Release/2019-02-22"
#define __amd64 1
#define __amd64__ 1
#define __x86_64 1
#define __x86_64__ 1

event_add failed. in cpsl

Hi,

I am getting below error in my setup.
comm_point_start_listening: comm point start listening 1030
comm_point_start_listening: event_add failed. in cpsl.

As per my analysis, it's failing due to below check.

if(ev->ev_fd != -1 && ev->ev_fd >= ev->ev_base->capfd)
return -1;

I would like to know, what is the reason for capping Max FD to 1024 (#define MAX_FDS 1024).
Will there be any impact if we increase this limit?

Thanks,
Janardhan.

NSD 4.3.0 does not start on FreeBSD

NSD 4.3.0 fails to start on FreeBSD with following error:

[2020-03-19 10:56:03.988] nsd[6411]: error: setsockopt(..., SO_SETFIB, 0, ...) failed: Bad address

The following change should fix this problem.

--- server.c.orig	2020-03-17 10:00:17 UTC
+++ server.c
@@ -1104,7 +1104,7 @@ set_setfib(struct nsd_socket *sock)
 {
 #if defined(SO_SETFIB)
 	if(setsockopt(sock->s, SOL_SOCKET, SO_SETFIB,
-	              (const void *)(uintptr_t)sock->fib, sizeof(sock->fib)) == -1)
+	              (const void *)&sock->fib, sizeof(sock->fib)) == -1)
 	{
 		log_msg(LOG_ERR, "setsockopt(..., %s, %d, ...) failed: %s",
 		                 "SO_SETFIB", sock->fib, strerror(errno));

IXFR falls back to AXFR when an earlier IXFR is in process of being applied

Multiple pattern support with nsd-control addzone

default configuration and systemd results in duplicate log messages

nsd, per default, logs both to stderr and syslog. As systemd forwards
both into journal all messages are included twice.

Ideally one could make nsd just use syslog and nothing else but
this does not seem to be possible.

This bug has been filed in Debian as
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803683

Also originally reported in https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4198

AXFR restart when zone is updated

If an update on the zone is received by NSD, and an AXFR of the zone is still running at that time, the AXFR transfer of the zone starts from the beginning of the zone again.
Therefore, certainly for a bigger zone, within the AXFR output, the first entries of the zone are shown mutiple times.
The AXFR output displays the following message when this happens:
;; communications error to <ipaddress>#53: end of file

DB backend for zone.list because zone deletion is slow

Doesn't reload zone when included files change

When I make a change to a file $INCLUDEd in a zone file, nsd cowardly refuses to reload the zone, claiming that the zone file hasn't been modified on disk. It hasn't, but nsd should be checking included files as well, and reload if any files in the include tree have been modified.

Out-of-bounds read caused by improper validation of array index

Hi,

While fuzzing nsd-checkzone with American Fuzzy Lop, I found an out-of-bounds read caused by improper validation of array index, in the rdata_maximum_wireformat_size() function, in rdata.c L873.

Attaching a reproducer (gzipped so GitHub accepts it), issue can be reproduced by running:

nsd-checkzone all.rr zone01

zone01.gz

NULL pointer dereference in domain_dname()

Hi,

While fuzzing nsd-checkzone with Honggfuzz, I found a NULL pointer dereference in the domain_dname() function.

I believe it was introduced by commit b4528a3.

Attaching a reproducer (gzipped so GitHub accepts it): zone04.gz

Issue can be reproduced by running:

nsd-checkzone all.rr zone04

In namedb.h L270 returning domain->dname results in a NULL pointer dereference because domain ends up being NULL:

#0  0x0000041f7a8f3e2b in domain_dname (domain=0x0) at namedb.h:270
270             return (dname_type *) domain->dname;

Configuration mangers (ansible, chef, puppet, salt, wffls) candidates for contrib?

Are configuration mangers candidates for contrib: ansible, chef, puppet, salt, wffls?

It would likely only make sense if they were included as sub-repos

The purpose (benefit) would be to record and coalesce best practices, share these between the various tools and improve default setups.

cpuid_t typedef on Linux appears incorrect

Hi Everyone,

My apologies if this is extra noise... The cpuset_t caught my eye during HURD and DragonFly compiles. Also see #73 and #75.

I believe the int type used for cpuid_t may be incorrect. Additionally, because cpuid_t could be a struct on 32-bit systems, you have to use memcpy rather then assignment to assign one. The man pages also state it:

   To duplicate a CPU set, use memcpy(3).

   Since CPU sets are bit masks allocated in units of long words, the
   actual number of CPUs in a dynamically allocated CPU set will be
   rounded up to the next multiple of sizeof(unsigned long).  An
   application should consider the contents of these extra bits to be
   undefined.

---

According to <compat/cpuset.h>, and focusing on Linux. Notice the int typedef.

#ifndef HAVE_CPUID_T
#ifdef __linux__
typedef int cpuid_t;
#endif
#ifdef __FreeBSD__
typedef size_t cpuid_t;
#endif
#endif

On Ubuntu 18.04 x86_64 fully patched:

$ grep -IR cpu_set_t /usr/include
/usr/include/x86_64-linux-gnu/bits/cpu-set.h:} cpu_set_t;
...

And then from /usr/include/x86_64-linux-gnu/bits/cpu-set.h:

typedef struct
{
  __cpu_mask __bits[__CPU_SETSIZE / __NCPUBITS];
} cpu_set_t;

Then, find __cpu_mask:

/usr/include/x86_64-linux-gnu/bits/cpu-set.h:typedef __CPU_MASK_TYPE __cpu_mask;

Then, find __CPU_MASK_TYPE:

$ grep -IR __CPU_MASK_TYPE /usr/include
/usr/include/x86_64-linux-gnu/bits/typesizes.h:#define __CPU_MASK_TYPE 	__SYSCALL_ULONG_TYPE

Then find __SYSCALL_ULONG_TYPE:

$ grep -IR __SYSCALL_ULONG_TYPE /usr/include
/usr/include/x86_64-linux-gnu/bits/typesizes.h:# define __SYSCALL_ULONG_TYPE	__UQUAD_TYPE
/usr/include/x86_64-linux-gnu/bits/typesizes.h:# define __SYSCALL_ULONG_TYPE	__ULONGWORD_TYPE

---

This is where the problems arise. __SYSCALL_ULONG_TYPE is either a 64-bit type (which is not an int):

/usr/include/x86_64-linux-gnu/bits/typesizes.h:# define __SYSCALL_ULONG_TYPE	__ULONGWORD_TYPE
...
/usr/include/x86_64-linux-gnu/bits/typesizes.h:# define __SYSCALL_ULONG_TYPE	__ULONGWORD_TYPE
/usr/include/x86_64-linux-gnu/bits/types.h:#define __ULONGWORD_TYPE	unsigned long int

Or it is either a struct (which is not an int) or unsigned long int (which is not an int):

$ grep -IR __UQUAD_TYPE /usr/include
...
/usr/include/x86_64-linux-gnu/bits/types.h:# define __UQUAD_TYPE		__u_quad_t
/usr/include/x86_64-linux-gnu/bits/types.h:# define __UQUAD_TYPE		unsigned long int

In either case, it is not an int. That seems to be important because nsd does this, which appears to slice the high word off:

./nsd.c:			cpuset_set((cpuid_t)opt->cpu, nsd.cpuset);
./nsd.c:			cpuset_set((cpuid_t)cpu, nsd.xfrd_cpuset);

---

And in case there is interest:

$ cat t.c
#include <stdio.h>
int main(void)
{
  printf("sizeof unsigned long int: %d\n", (int)(sizeof(unsigned long int)));
}

And then:

$ ./t
sizeof unsigned long int: 8

---

Here's the 32-bit case to save you the trouble:

/* quad_t is also 64 bits.  */
#if __WORDSIZE == 64
typedef long int __quad_t;
typedef unsigned long int __u_quad_t;
#elif defined __GLIBC_HAVE_LONG_LONG
__extension__ typedef long long int __quad_t;
__extension__ typedef unsigned long long int __u_quad_t;
#else
typedef struct
{
  long __val[2];
} __quad_t;
typedef struct
{
  __u_long __val[2];
} __u_quad_t;
#endif

segfault in libc-2.29.so

Aug  5 15:43:46 home nsd[145459]: control cmd:  stats
Aug  5 15:48:46 home nsd[145459]: new control connection from 127.0.0.1
Aug  5 15:48:46 home nsd[145459]: control cmd:  stats
Aug  5 15:53:46 home nsd[145459]: new control connection from 127.0.0.1
Aug  5 15:53:46 home nsd[145459]: control cmd:  stats
Aug  5 15:53:46 home nsd[145460]: process 171339 terminated with status 11
Aug  5 15:53:46 home kernel: [2179729.697922] nsd[171339]: segfault at 5569a65eccd8 ip 00007fe293b15a90 sp 00007ffc90343960 error 4 in libc-2.29.so[7fe293aac000+159000]
Aug  5 15:53:46 home kernel: nsd[171339]: segfault at 5569a65eccd8 ip 00007fe293b15a90 sp 00007ffc90343960 error 4 in libc-2.29.so[7fe293aac000+159000]

4.2.0 crash in SSL library

#0  0x00007fd31aed6479 in SSL_shutdown () from /lib64/libssl.so.1.1
#1  0x000055941263b45e in cleanup_tcp_handler (data=0x559423f89d70) at server.c:3000
#2  0x000055941263bae8 in handle_tcp_reading (fd=<optimized out>, event=<optimized out>, arg=0x559423f89d70) at server.c:3188
#3  0x00007fd31ab6cb17 in ?? () from /lib64/libevent-2.1.so.6
#4  0x00007fd31ab6d287 in event_base_loop () from /lib64/libevent-2.1.so.6
#5  0x000055941263ed27 in server_child (nsd=nsd@entry=0x5594126c8c00 <nsd>) at server.c:2652
#6  0x000055941263f145 in restart_child_servers (nsd=nsd@entry=0x5594126c8c00 <nsd>, region=region@entry=0x5594184011d0, netio=netio@entry=0x559422d847b0, xfrd_sock_p=0x55941412e700) at server.c:427
#7  0x000055941263f43c in server_start_children (xfrd_sock_p=<optimized out>, netio=0x559422d847b0, region=0x5594184011d0, nsd=0x5594126c8c00 <nsd>) at server.c:1223
#8  server_reload (nsd=nsd@entry=0x5594126c8c00 <nsd>, server_region=server_region@entry=0x5594184011d0, netio=netio@entry=0x559422d847b0, cmdsocket=26) at server.c:1977
#9  0x000055941263ff99 in server_main (nsd=0x5594126c8c00 <nsd>) at server.c:2270
#10 0x00005594125fe15a in main (argc=<optimized out>, argv=<optimized out>) at nsd.c:1147

(gdb) up
#1  0x000055941263b45e in cleanup_tcp_handler (data=0x559423f89d70) at server.c:3000
3000			SSL_shutdown(data->tls);
(gdb) print data
$1 = (struct tcp_handler_data *) 0x559423f89d70
(gdb) print *data
$2 = {region = 0x55942084bcf0, nsd = 0x5594126c8c00 <nsd>, query = 0x5594241ff460, query_state = QUERY_PROCESSED, event = {ev_evcallback = {evcb_active_next = {tqe_next = 0x0, tqe_prev = 0x5594170526d0}, evcb_flags = 128, evcb_pri = 0 '\000', evcb_closure = 2 '\002', 
      evcb_cb_union = {evcb_callback = 0x55941263b860 <handle_tcp_reading>, evcb_selfcb = 0x55941263b860 <handle_tcp_reading>, evcb_evfinalize = 0x55941263b860 <handle_tcp_reading>, evcb_cbfinalize = 0x55941263b860 <handle_tcp_reading>}, evcb_arg = 0x559423f89d70}, 
    ev_timeout_pos = {ev_next_with_common_timeout = {tqe_next = 0xffffffff, tqe_prev = 0x0}, min_heap_idx = -1}, ev_fd = 30, ev_base = 0x559422ea58b0, ev_ = {ev_io = {ev_io_next = {le_next = 0x0, le_prev = 0x559417ae9130}, ev_timeout = {tv_sec = 120, tv_usec = 0}}, ev_signal = {
        ev_signal_next = {le_next = 0x0, le_prev = 0x559417ae9130}, ev_ncalls = 120, ev_pncalls = 0x0}}, ev_events = 19, ev_res = 2, ev_timeout = {tv_sec = 2642933, tv_usec = 261420}}, bytes_transmitted = 0, query_count = 1, tcp_timeout = 120000, tls = 0x6501300130013001, 
  shake_state = 805398017}

TLS related config in /etc/nsd/nsd.conf

        tls-service-pem: "/etc/letsencrypt/live/puck.nether.net/cert.pem"
        # tls-service-ocsp: "path/to/ocsp.pem"
        tls-port: 853

crash in nsd ec8d14f8aa32903e894033c678a7268091002a92

#0  0x000055ccdaa1457b in rbtree_next (node=0x74656e0369746c61) at rbtree.c:522
522		if (node->right != RBTREE_NULL) {
Missing separate debuginfos, use: dnf debuginfo-install fstrm-0.4.0-3.fc30.x86_64 glibc-2.29-15.fc30.x86_64 libevent-2.1.8-5.fc30.x86_64 libgcc-9.1.1-1.fc30.x86_64 openssl-libs-1.1.1c-2.fc30.x86_64 protobuf-c-1.3.1-2.fc30.x86_64 zlib-1.2.11-15.fc30.x86_64
(gdb) bt
#0  0x000055ccdaa1457b in rbtree_next (node=0x74656e0369746c61) at rbtree.c:522
#1  0x000055ccdaa088cd in hash_tree_clear (tree=0x55cce8b12740) at namedb.c:301
#2  0x000055ccdaa0a8b9 in nsec3_clear_precompile (db=db@entry=0x55ccdd29c5d0, zone=zone@entry=0x55cce8af3f00) at nsec3.c:406
#3  0x000055ccdaa38b16 in apply_ixfr (softfail=0x7fff8a0f5e60, bytes=<synthetic pointer>, patname=0x7fff8a0f5ea0 "_implicit_svanheule.net", zone_res=<synthetic pointer>, 
    udbz=0x0, rr_count=<synthetic pointer>, delete_mode=<synthetic pointer>, is_axfr=<synthetic pointer>, seq_total=1, seq_nr=0, opt=0x55ccdca7c6d0, serialno=2018111243, 
    zone=0x7fff8a0f66a0 "svanheule.net.", in=0x55cce34c1ef0, db=<optimized out>) at difffile.c:1141
#4  apply_ixfr_for_zone (nsd=nsd@entry=0x55ccdaacac00 <nsd>, zonedb=zonedb@entry=0x55cce8af3f00, in=in@entry=0x55cce34c1ef0, opt=0x55ccdca7c6d0, 
    taskudb=taskudb@entry=0x55ccdd276560, last_task=last_task@entry=0x7fff8a0f87e0, xfrfilenr=2324) at difffile.c:1357
#5  0x000055ccdaa39a26 in task_process_apply_xfr (task=0x7fff8a0f8800, task=0x7fff8a0f8800, last_task=0x7fff8a0f87e0, udb=0x55ccdd276560, nsd=0x55ccdaacac00 <nsd>)
    at difffile.c:2028
#6  task_process_in_reload (nsd=nsd@entry=0x55ccdaacac00 <nsd>, udb=udb@entry=0x55ccdd276560, last_task=last_task@entry=0x7fff8a0f87e0, task=task@entry=0x7fff8a0f8800)
    at difffile.c:2082
#7  0x000055ccdaa413e7 in reload_process_tasks (cmdsocket=26, last_task=0x7fff8a0f87e0, nsd=0x55ccdaacac00 <nsd>) at server.c:1869
#8  server_reload (nsd=nsd@entry=0x55ccdaacac00 <nsd>, server_region=server_region@entry=0x55cce1807d40, netio=netio@entry=0x55cceb6c5360, cmdsocket=26) at server.c:1962
#9  0x000055ccdaa42099 in server_main (nsd=0x55ccdaacac00 <nsd>) at server.c:2281
#10 0x000055ccdaa0013a in main (argc=<optimized out>, argv=<optimized out>) at nsd.c:1147
(gdb) print node
$1 = (rbnode_type *) 0x74656e0369746c61
(gdb) print *node
Cannot access memory at address 0x74656e0369746c61
(gdb) up
#1  0x000055ccdaa088cd in hash_tree_clear (tree=0x55cce8b12740) at namedb.c:301
301			n->key = NULL;
(gdb) print tree
$2 = (rbtree_type *) 0x55cce8b12740
(gdb) print *tree
$3 = {region = 0x55ccdd2682a0, root = 0x55cce8b128f8, count = 38, _node = 0x0, cmp = 0x55ccdaa09570 <cmp_hash_tree>}
(gdb) up
#2  0x000055ccdaa0a8b9 in nsec3_clear_precompile (db=db@entry=0x55ccdd29c5d0, zone=zone@entry=0x55cce8af3f00) at nsec3.c:406
406		hash_tree_clear(zone->hashtree);
(gdb) print *zone
$4 = {node = 0x55cce8af3f88, apex = 0x55cce0259fb0, soa_rrset = 0x55cce8af4070, soa_nx_rrset = 0x55cce8af9dc8, ns_rrset = 0x55cce8afaf78, nsec3_param = 0x55cce8afb358, 
  nsec3_last = 0x55cce8b0efc8, nsec3tree = 0x55cce8b11758, hashtree = 0x55cce8b12740, wchashtree = 0x55cce8b12768, dshashtree = 0x55cce8b130a0, opts = 0x55ccdd128348, 
  filename = 0x55cce8b116c8 "/etc/nsd/secondaries/svanheule.net", logstr = 0x0, mtime = {tv_sec = 1542036631, tv_nsec = 159757247}, zonestatid = 0, is_secure = 1, 
  is_ok = 0, is_changed = 0}
(gdb) up
#3  0x000055ccdaa38b16 in apply_ixfr (softfail=0x7fff8a0f5e60, bytes=<synthetic pointer>, patname=0x7fff8a0f5ea0 "_implicit_svanheule.net", zone_res=<synthetic pointer>, 
    udbz=0x0, rr_count=<synthetic pointer>, delete_mode=<synthetic pointer>, is_axfr=<synthetic pointer>, seq_total=1, seq_nr=0, opt=0x55ccdca7c6d0, serialno=2018111243, 
    zone=0x7fff8a0f66a0 "svanheule.net.", in=0x55cce34c1ef0, db=<optimized out>) at difffile.c:1141
1141				nsec3_clear_precompile(db, zone_db);
(gdb) print db
$5 = <optimized out>
(gdb) print zone_db
$6 = (zone_type *) 0x55cce8af3f00
(gdb) print *zone_db
$7 = {node = 0x55cce8af3f88, apex = 0x55cce0259fb0, soa_rrset = 0x55cce8af4070, soa_nx_rrset = 0x55cce8af9dc8, ns_rrset = 0x55cce8afaf78, nsec3_param = 0x55cce8afb358, 
  nsec3_last = 0x55cce8b0efc8, nsec3tree = 0x55cce8b11758, hashtree = 0x55cce8b12740, wchashtree = 0x55cce8b12768, dshashtree = 0x55cce8b130a0, opts = 0x55ccdd128348, 
  filename = 0x55cce8b116c8 "/etc/nsd/secondaries/svanheule.net", logstr = 0x0, mtime = {tv_sec = 1542036631, tv_nsec = 159757247}, zonestatid = 0, is_secure = 1, 
  is_ok = 0, is_changed = 0}
(gdb) up
#4  apply_ixfr_for_zone (nsd=nsd@entry=0x55ccdaacac00 <nsd>, zonedb=zonedb@entry=0x55cce8af3f00, in=in@entry=0x55cce34c1ef0, opt=0x55ccdca7c6d0, 
    taskudb=taskudb@entry=0x55ccdd276560, last_task=last_task@entry=0x7fff8a0f87e0, xfrfilenr=2324) at difffile.c:1357
1357				ret = apply_ixfr(nsd->db, in, zone_buf, new_serial, opt,
(gdb) print nsd->db
$8 = (struct namedb *) 0x55ccdd29c5d0
(gdb) print *in
$9 = {_flags = -72539000, _IO_read_ptr = 0x55cce34c520f "", 
  _IO_read_end = 0x55cce34c5260 "\374\066\064\t\"\373\266bb\037=M\202[\321&\277C\267\346ъ\027\066C\265\215l\\we\221\nG\345Q\255\326\213\267)\337\026%\375\373\070\314\302\001\001", 
  _IO_read_base = 0x55cce34c4460 "\343\bc\374Xx>\210\217[K\370\256ݲ幓\254j\367\302E\271\271\250\330\376\221\244\"䍨\316l,\277-\307G&L\273\002\261\002$\374\023\261\177\026\071Jo8\304cK.\270zf\333o鄾\355\266\263\205\210ΏX\260\242cŇ$\355}\220\263f\300", 
  _IO_write_base = 0x55cce34c4460 "\343\bc\374Xx>\210\217[K\370\256ݲ幓\254j\367\302E\271\271\250\330\376\221\244\"䍨\316l,\277-\307G&L\273\002\261\002$\374\023\261\177\026\071Jo8\304cK.\270zf\333o鄾\355\266\263\205\210ΏX\260\242cŇ$\355}\220\263f\300", 
  _IO_write_ptr = 0x55cce34c4460 "\343\bc\374Xx>\210\217[K\370\256ݲ幓\254j\367\302E\271\271\250\330\376\221\244\"䍨\316l,\277-\307G&L\273\002\261\002$\374\023\261\177\026\071Jo8\304cK.\270zf\333o鄾\355\266\263\205\210ΏX\260\242cŇ$\355}\220\263f\300", 
  _IO_write_end = 0x55cce34c4460 "\343\bc\374Xx>\210\217[K\370\256ݲ幓\254j\367\302E\271\271\250\330\376\221\244\"䍨\316l,\277-\307G&L\273\002\261\002$\374\023\261\177\026\071Jo8\304cK.\270zf\333o鄾\355\266\263\205\210ΏX\260\242cŇ$\355}\220\263f\300", 
  _IO_buf_base = 0x55cce34c4460 "\343\bc\374Xx>\210\217[K\370\256ݲ幓\254j\367\302E\271\271\250\330\376\221\244\"䍨\316l,\277-\307G&L\273\002\261\002$\374\023\261\177\026\071Jo8\304cK.\270zf\333o鄾\355\266\263\205\210ΏX\260\242cŇ$\355}\220\263f\300", _IO_buf_end = 0x55cce34c5460 "\020\020", _IO_save_base = 0x0, _IO_backup_base = 0x0, 
  _IO_save_end = 0x0, _markers = 0x0, _chain = 0x55ccdd276880, _fileno = 25, _flags2 = 0, _old_offset = -8478963733504460626, _cur_column = 0, _vtable_offset = 116 't', 
  _shortbuf = "m", _lock = 0x55cce34c1fd0, _offset = -1, _codecvt = 0x3a041bf52372e1d8, _wide_data = 0x55cce34c1fe0, _freeres_list = 0x0, _freeres_buf = 0x8bbcfa86592fb5cd, 
  __pad5 = 18130380083877570558, _mode = -1, _unused2 = "\242\220\326:۔I\260O\201\324!\022\231\230\376\264\251\215Z"}

Make test depends on tpkg no included in release tarballs

PR #72 added a test check target. This fails in release tarballs due to excluded tpkg directory.

Debhelper calls make test by default as part of the dh_auto_test target, making this break standard Debian packaging as well.

Is remote-control: a top-level attribute?

The manual for nsd.conf says: At the top level only server: and key: and pattern: and zone: are allowed. Apparently remote-control belongs also to the top level.

Stack-based Buffer Overflow in the dname_concatenate() function

Hi,

While fuzzing nsd-checkzone with American Fuzzy Lop, I found a Stack-based Buffer Overflow in the dname_concatenate() function, in dname.c L464.

Attaching a reproducer (gzipped so GitHub accepts it), issue can be reproduced by running:

nsd-checkzone all.rr zone02

zone02.gz

=================================================================
==7395==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffcd6a9763f at pc 0x0000004dadbc bp 0x7ffcd6a97510 sp 0x7ffcd6a96cc0
WRITE of size 8 at 0x7ffcd6a9763f thread T0
#0 0x4dadbb in __asan_memcpy (/home/fcambus/nsd/nsd-checkzone+0x4dadbb)
#1 0x534251 in dname_concatenate /home/fcambus/nsd/dname.c:464:2
#2 0x69e61f in yyparse /home/fcambus/nsd/./zparser.y:1024:12
#3 0x689fd1 in zonec_read /home/fcambus/nsd/zonec.c:1623:2
#4 0x6aedd1 in check_zone /home/fcambus/nsd/nsd-checkzone.c:61:11
#5 0x6aea07 in main /home/fcambus/nsd/nsd-checkzone.c:127:2
#6 0x7fa60ece6b96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
#7 0x41c1d9 in _start (/home/fcambus/nsd/nsd-checkzone+0x41c1d9)

Address 0x7ffcd6a9763f is located in stack of thread T0 at offset 287 in frame
#0 0x533f8f in dname_concatenate /home/fcambus/nsd/dname.c:458

This frame has 1 object(s):
[32, 287) 'temp' (line 459) <== Memory access at offset 287 overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions are supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow (/home/fcambus/nsd/nsd-checkzone+0x4dadbb) in __asan_memcpy
Shadow bytes around the buggy address:
0x10001ad4ae70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001ad4ae80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001ad4ae90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001ad4aea0: 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00
0x10001ad4aeb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10001ad4aec0: 00 00 00 00 00 00 00[07]f3 f3 f3 f3 f3 f3 f3 f3
0x10001ad4aed0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001ad4aee0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001ad4aef0: 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00
0x10001ad4af00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001ad4af10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==7395==ABORTING

4.2.2 - TLS handshake failed

Sep 26 07:36:41 puck nsd[1576860]: TLS handshake failed
Sep 26 07:36:41 puck nsd[1576539]: [2019-09-26 07:36:41.561] nsd[1576860]: error: TLS handshake failed
Sep 26 07:36:41 puck nsd[1576860]: TLS handshake failed
Sep 26 07:36:41 puck nsd[1576539]: [2019-09-26 07:36:41.595] nsd[1576860]: error: TLS handshake failed
Sep 26 07:36:47 puck nsd[1576860]: TLS handshake failed
Sep 26 07:36:47 puck nsd[1576539]: [2019-09-26 07:36:47.577] nsd[1576860]: error: TLS handshake failed
Sep 26 07:36:47 puck nsd[1576860]: TLS handshake failed
Sep 26 07:36:47 puck nsd[1576539]: [2019-09-26 07:36:47.619] nsd[1576860]: error: TLS handshake failed

Logs contain the above messages without any further details. I'm thinking it should provide the IP address in the log message if possible, as well as perhaps reducing duplicate logs or it being a debug/traceoption

Create a list of NSD users

While many companies offer DNSSEC hosting, very often the implementation is not correct (e.g. EDNS0 is broken). Please collect voluntary provided information of who uses NSD, so that the users can assume from that list, that the mentioned providers offers correctly implemented DNS service.

NULL pointer dereference in rdata_atom_size()

Hi,

While fuzzing nsd-checkzone with Honggfuzz, I found a NULL pointer dereference in the rdata_atom_size() function.

I believe it was introduced by commit b4528a3.

Attaching a reproducer (gzipped so GitHub accepts it): zone03.gz

Issue can be reproduced by running:

nsd-checkzone all.rr zone03

In namedb.h L347 returning *atom.data results in a NULL pointer dereference because atom.data ends up being NULL:

#0  0x00000dd0a0deb360 in rdata_atom_size (atom={domain = 0x0, data = 0x0}) at namedb.h:347
347             return *atom.data;

GNU HURD and nsd.c:352:19: warning: cast from pointer to integer of different size

Hi Everyone,

I'm testing nsd master on GNU HURD. The HURD image is dated JAN 2020, and is fully patched. HURD is a GNU Linux operating system with a personality. It is also i386, not x86_64.

Bootstrap and configure go well. Below is the output of make.

gcc -I. -I/usr/local/include -g -O2 -flto -c nsd.c
nsd.c: In function ‘find_device’:
nsd.c:352:19: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  352 |    len = (size_t)((uintmax_t)colon - (uintmax_t)ifa->ifa_name);
      |                   ^
nsd.c:352:38: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  352 |    len = (size_t)((uintmax_t)colon - (uintmax_t)ifa->ifa_name);
      |                                      ^

I am not familiar with the use of the uintmax_t type. I believe the way to proceed is, (1) add std=c99 compile option; or (2) cast the pointer to a uintptr_t. Though uintptr_t is optional, it is ubiquitous based on my testing.

(This was encountered after clearing #73).

Excessive logging

I'm seeing cases with excessive logging, eg:

This seems to be impacting the way the system responds, perhaps there's some issue being raised here in the trasnfer of these domains from this server?

Sep  3 20:46:30 puck nsd[852]: [2019-09-03 20:46:30.543] nsd[852]: error: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: [2019-09-03 20:46:30.545] nsd[852]: error: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: [2019-09-03 20:46:30.548] nsd[852]: error: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: [2019-09-03 20:46:30.550] nsd[852]: error: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: [2019-09-03 20:46:30.551] nsd[852]: error: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: [2019-09-03 20:46:30.554] nsd[852]: error: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: [2019-09-03 20:46:30.555] nsd[852]: error: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: [2019-09-03 20:46:30.557] nsd[852]: error: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: [2019-09-03 20:46:30.560] nsd[852]: error: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: [2019-09-03 20:46:30.562] nsd[852]: error: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: [2019-09-03 20:46:30.565] nsd[852]: error: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: [2019-09-03 20:46:30.568] nsd[852]: error: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: [2019-09-03 20:46:30.570] nsd[852]: error: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: [2019-09-03 20:46:30.573] nsd[852]: error: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: [2019-09-03 20:46:30.575] nsd[852]: error: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: [2019-09-03 20:46:30.578] nsd[852]: error: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: [2019-09-03 20:46:30.580] nsd[852]: error: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51
Sep  3 20:46:30 puck nsd[852]: xfrd: zone fleischer.hu received error code NOT IMPL from 173.245.58.51

NSD additional section truncated

Hello,
We noticed that the additional section in a DNS reply from NSD is truncated.
See example below.
We are currently running NSD v4.1.24-2.
In NSD v4.2.1 are 2 new parameters introduced (send-buffer-size and receive-buffer-size; https://www.nlnetlabs.nl/news/2019/Jul/09/nsd-4.2.1-released/); will configuring these parameters to a higher value, have NSD send back the complete additional section ?
If not, how can we adjust NSD to sent back the complete additional section ?

dig @172.17.32.2 +bufsize=4096 dns.be -t A +notcp +dnssec

; <<>> DiG 9.11.7-RedHat-9.11.7-2.el7 <<>> @172.17.32.2 +bufsize=4096 dns.be -t A +notcp +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1162
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 5
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;dns.be. IN A

;; ANSWER SECTION:
dns.be. 60 IN A 107.154.248.139
dns.be. 60 IN RRSIG A 8 2 60 20190913145959 20190903144514 30315 dns.be. PABuufraNBwaMwfgEKBG/M+JzYNr4imS9n2dWQ5+0BrmkylqmyunUdWl ltd4dB+H3j5o3QaQN739zIgSjk/Yi5P2Ip3A9hxRg+axt9+jlJSLjZcY i76nP7h5bGSTS/dzuRyEBht64M8oGnyzhzou2i9m0aGBnBNw82zD9VgN PJDaY+YfHHkvAiK5bPwOmFfLBywVQxoygceiFMS1YOoNawSeY65T+6hV 4MSJmon+IQWiQd0rWm+AajZZDuMW1B3YT/ByMMMw63j4/pG8CrOOhBzJ PFVrZOSPrhNM6jOOxr/3rBYdmqwbaNnfW10RK62svb+eD5eu6X4OWqFd cBUZzQ==

;; AUTHORITY SECTION:
dns.be. 86400 IN NS d.ns.dns.be.
dns.be. 86400 IN NS a.ns.dns.be.
dns.be. 86400 IN NS b.ns.dns.be.
dns.be. 86400 IN NS c.ns.dns.be.
dns.be. 86400 IN NS x.ns.dns.be.
dns.be. 86400 IN NS y.ns.dns.be.
dns.be. 86400 IN RRSIG NS 8 2 86400 20190916061726 20190906061640 30315 dns.be. fr5Ix0FiZlNKAmISFfp9KKSlaIcYEhPm9ZIfXs6UuZTeR46HT2hTLApO cAvZl0D90nOUsq3D0Icmj2wsWqaewec9pf32/RgcQSNqKejpUn1amaO1 zBkW9KLrhCftWYxncyp8HDwsxsFWGJxg8Md4w5+/Z8Wc7TBL9zNZPT2t AgFs1QjNI145vc2CjSLriUsWWYKhx9ickLynGvNihlrV0EZSZ9S1eZx6 blrIfx+pyMCxQAe31KhTh01MYXCZvlrJUrnfPDdNtxHmVGJ9EOaqJyce l+OkPNsFGzvkYloppI089vLD6sHS2YitX+W6wRdI/BBvvot/gFnvGp19 dTi8Zw==

;; ADDITIONAL SECTION:
d.ns.dns.be. 86400 IN A 194.0.44.1
d.ns.dns.be. 86400 IN RRSIG A 8 4 86400 20190913134317 20190903133143 30315 dns.be. dN6PlAFKdsEsH2ccYlSrnpvAgOFSyyyPahcC5LB5C24+vGQcBKuOW2h9 aRyJ8RKIiDNV+D8nNt0ySLeeBRSF3R1MbTjiZlPfrmfQPNU9DuewjeHM q8fa+yKhStEp191ZuyBuonYfO5J2lEmWvICtauh7b5QYFt46G6iXrmGt AjxMtVMOYx2K8dKMqHgeJkGrQRJkdyoZ13UJKaFh1dQdNuwfApFs9ZMR GVRUNW1Aj0/SrSlh5K297Xb+A0g/donCvzS1GbSePa8yv16paYRYGu+U 8C64IkV3EehBXVQYc1TW30LTnN7hzJTaZB4iE4qNN/Ch6cSuMzuOJccs eGyz8g==
a.ns.dns.be. 86400 IN A 194.0.6.1
a.ns.dns.be. 86400 IN RRSIG A 8 4 86400 20190913133954 20190903130316 30315 dns.be. ds/0ZsjajUfvg4JJOlp8KrrBrwV/iAqaK4XKLQwb6Avi6+BM9TU4MCnR QGS3kmfl8KFSmeUc1L2/zXAmZYvKB/IcsDDuBwc6lpQqgts1Wt5ai+lo +x0kYm7j8A/lry41k/JsuG+6fgITSH59HJz19pqRNUKEceB+g3tQIOwX cdGLH0rngnM2T0mku0Oqs4QI9VGHszoJVEoc6lQ/ENvHdMTb4ygQG+Wm ug4YogRDXMsUp75Cucc81UGwrXy6+ChFaNMB281Fc4dAmMBe2KKQLa2F oeeXaSQxAa4Cqc+s9a3/czc+huddQbaOwPVcr6TUdg6uthgqpv4c7lag c4Z5uQ==

;; Query time: 0 msec
;; SERVER: 172.17.32.2#53(172.17.32.2)
;; WHEN: Fri Sep 06 14:43:31 CEST 2019
;; MSG SIZE rcvd: 1358

configure.ac and Makefile.in hard codes tools

I'm testing NSD master on Solaris 11.3. There are several problems with compile that trace back to lack of precious variables for tools. What happens is, I set a tool like EGREP=ggrep -E, but the hardcoded egrep is used. There are two problems. First, tools like grep and egrep are not Posix; and second, Solaris managed to provide tools that are more anemic then Posix.

The fix is threefold. First, declare the tools as precious in configure.ac using AC_ARG_VAR:

AC_ARG_VAR(SED, [location of the sed program])
AC_ARG_VAR(AWK, [location of the awk program])
AC_ARG_VAR(GREP, [location of the grep program])
...

Second, perform the tool tests early:

AC_PROG_CC
AC_PROG_SED
AC_PROG_AWK
AC_PROG_GREP
AC_PROG_EGREP
AC_PROG_LN_S
AC_PROG_INSTALL
AC_PROG_LEX
AC_PROG_YACC

Third, use the variables in configure and Makefile. So Makefile.in would be changed to:

SED 	= @SED@
AWK 	= @AWK@
GREP	= @GREP@
EGREP	= @EGREP@
YACC 	= @YACC@
LEX 	= @LEX@
...

head -`$(EGREP) -n "# Dependencies" $(DEPEND_TARGET) | tail -1 | $(SED) -e 's/:.*$$//'` $(DEPEND_TMP2) > $(DEPEND_TARGET)

After the change I was able to get through a compile on Solaris using standard tools sans one error due to an ancient version of OpenSSL.

---

Making the tools precious variables results in the following when running ./configure --help:

Some influential environment variables:
  SED         location of the sed program
  AWK         location of the awk program
  GREP        location of the grep program
  EGREP       location of the egrep program
  LEX         location of the lex program with GNU extensions (flex)
  YACC        location of the yacc program with GNU extensions (bison)
  CC          C compiler command
  ...

---

Here is a difference in output between Linux and Solaris with precious variables.

Linux

$ ./configure
...
checking for a sed that does not truncate output... /bin/sed
checking for gawk... gawk
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for flex... flex
...

$ make
...
/bin/sed -e 's,@prefix\@,/usr/local,g' -e 's,@exec_prefix\@,/usr/local,g' ...

Solaris

$ ./configure
...
checking for a sed that does not truncate output... /usr/bin/gsed
checking for gawk... gawk
checking for grep that handles long lines and -e... /usr/bin/ggrep
checking for egrep... /usr/bin/ggrep -E
checking for flex... flex
...

$ make
...
/usr/bin/gsed  -e 's,@prefix\@,/usr/local,g'  -e 's,@exec_prefix\@,/usr/local,g' ...

Look into alternative methods (instead of writing to disk) for receiving IXFR's and applying them

NSD doesn't refresh zones after extended downtime

I have a test server, where I had last run NSD in March 2019. Then I had shut it down. Today, I installed a new version of NSD, and started it. It has 3 slave zones configured. The log showed this:

[2019-07-18 10:02:56.198] nsd[1187]: notice: nsd starting (NSD 4.2.1)
[2019-07-18 10:02:56.765] nsd[1188]: info: zone . read with success
[2019-07-18 10:02:56.768] nsd[1188]: info: zone arpa. read with success
[2019-07-18 10:02:56.768] nsd[1188]: info: zone root-servers.net. read with success
[2019-07-18 10:02:56.768] nsd[1188]: notice: nsd started (NSD 4.2.1), pid 1187
[2019-07-18 10:06:10.608] nsd[1188]: warning: signal received, shutting down...

Notice that NSD did not refresh any of the zones, even though they are vastly out of date. Now, this is caused by the timers on xfrd.state (which is shown below). I think the issue here is that NSD isn't checking the time of the state file with current system time, and so doesn't realise that the refresh timers are too old, and that it should immediately refresh these zones. Even at exit, it still saves the refresh timers, and won't update if I start it again. I think the value of next_timeout should take into account the current system time.

NSDXFRD2
# This file is written on exit by nsd xfr daemon.
# This file contains slave zone information:
#       * timeouts (when was zone data acquired)
#       * state (OK, refreshing, expired)
#       * which master transfer to attempt next
# The file is read on start (but not on reload) by nsd xfr daemon.
# You can edit; but do not change statement order
# and no fancy stuff (like quoted "strings").
#
# If you remove a zone entry, it will be refreshed.
# This can be useful for an expired zone; it revives
# the zone temporarily, from refresh-expiry time.
# If you delete the file all slave zones are updated.
#
# Note: if you edit this file while nsd is running,
#       it will be overwritten on exit by nsd.

filetime: 1563444370    # Thu Jul 18 10:06:10 2019

# The number of zone entries in this file
numzones: 3

zone:   name: .
        state: 0 # OK
        master: 0
        next_master: -1
        round_num: -1
        next_timeout: 1707      # = 28m 27s
        backoff: 0
        soa_nsd_acquired: 1553543862    # was 114d 14h 8m 28s ago
        soa_nsd: 6 1 86400 1792 a.root-servers.net. nstld.verisign-grs.com. 2019032501 1800 900 604800 86400
        # refresh = 30m retry = 15m expire = 7d minimum = 1d
        soa_disk_acquired: 1563444176   # was 3m 14s ago
        soa_disk: 6 1 86400 1792 a.root-servers.net. nstld.verisign-grs.com. 2019032501 1800 900 604800 86400
        # refresh = 30m retry = 15m expire = 7d minimum = 1d
        soa_notify_acquired: 0

zone:   name: arpa.
        state: 0 # OK
        master: 0
        next_master: -1
        round_num: -1
        next_timeout: 1572      # = 26m 12s
        backoff: 0
        soa_nsd_acquired: 1553543862    # was 114d 14h 8m 28s ago
        soa_nsd: 6 1 86400 1792 a.root-servers.net. nstld.verisign-grs.com. 2019032501 1800 900 604800 86400
        # refresh = 30m retry = 15m expire = 7d minimum = 1d
        soa_disk_acquired: 1563444176   # was 3m 14s ago
        soa_disk: 6 1 86400 1792 a.root-servers.net. nstld.verisign-grs.com. 2019032501 1800 900 604800 86400
        # refresh = 30m retry = 15m expire = 7d minimum = 1d
        soa_notify_acquired: 0

zone:   name: root-servers.net.
        state: 0 # OK
        master: 0
        next_master: -1
        round_num: -1
        next_timeout: 12555     # = 3h 29m 15s
        backoff: 0
        soa_nsd_acquired: 1553543861    # was 114d 14h 8m 29s ago
        soa_nsd: 6 1 3600000 1792 a.root-servers.net. nstld.verisign-grs.com. 2019031301 14400 7200 1209600 3600000
        # refresh = 4h retry = 2h expire = 14d minimum = 41d 16h
        soa_disk_acquired: 1563444176   # was 3m 14s ago
        soa_disk: 6 1 3600000 1792 a.root-servers.net. nstld.verisign-grs.com. 2019031301 14400 7200 1209600 3600000
        # refresh = 4h retry = 2h expire = 14d minimum = 41d 16h
        soa_notify_acquired: 0

NSDXFRD2

Have dnstap info send to external dnstap collector

Massive error logging under heavy server load

When the server is unable to respond all queries due to saturated network, it emits plenty of logs:

[2019-11-25 13:26:59.379] nsd[146817]: error: sendto 192.168.200.20 failed: Resource temporarily unavailable

Verbosity logging level: default

Stray dot at the end of some log entries

I've just noticed an anomaly when parsing NSD logs. Most logs don't end with a dot, but one of the logs looks like this:

[2019-06-10 12:22:44.131] nsd[15690]: info: zone arpa. serial 2019061000 is updated to 2019061001.

It is unusual for log entries to end with a dot. It doesn't serve any purpose, and in this case, extracting the serial from this line gives me an unexpected value, with a dot at the end.