NSD not logging to SYSLOG

NSD
1

Hi,

Running NSD on OpenBSD 5.4, I notice that nsd does not log to SYSLOG unless it
is run on the command line with the "-d -V 9" flags.

From the manpages:

-l logfile
        Log messages to the specified logfile. The default is to log to
        stderr and syslog. If a zonesdir: is specified in the config
        file this path can be relative to that directory.

Running it as a normal daemon with "-V 2" flags should theoretically log to
SYSLOG but it is not the case.
When running, no socket file is created in the /var/nsd/dev/ directory (even
if I changed the permission to _nsd:_nsd), is this normal?

Would appreciate any hint or help,

Cheers,
cam

Some info:
# nsd -v
NSD version 3.2.15
Written by NLnet Labs.

Copyright (C) 2001-2011 NLnet Labs. This is free software.
There is NO warranty; not even for MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE.

# l /var/nsd/
total 28
drwxr-xr-x 7 root wheel 512 Feb 16 11:29 .
drwxr-xr-x 25 root wheel 512 Feb 16 11:23 ..
drwxr-xr-x 2 root wheel 512 Feb 13 19:32 db
drwxr-xr-x 2 root wheel 512 Jul 31 2013 dev
drwxrwxr-x 2 root _nsd 512 Feb 16 14:14 run
drwxr-xr-x 2 root wheel 512 Jul 31 2013 zones

# cat /etc/nsd.conf
server:
    ip-address: 0.0.0.0
    port: 53
    server-count: 1
    statistics: 120
    verbosity: 2
    ip4-only: yes
    hide-version: yes
    identity: "ns1.domain.tld"

2

Hi Cam,

Hi,

Running NSD on OpenBSD 5.4, I notice that nsd does not log to
SYSLOG unless it is run on the command line with the "-d -V 9"
flags.

From the manpages:

-l logfile Log messages to the specified logfile. The default is to
log to stderr and syslog. If a zonesdir: is specified in the
config file this path can be relative to that directory.

Running it as a normal daemon with "-V 2" flags should
theoretically log to SYSLOG but it is not the case. When running,
no socket file is created in the /var/nsd/dev/ directory (even if I
changed the permission to _nsd:_nsd), is this normal?

Would appreciate any hint or help,

The chroot is likely the culprit. With chroot: "" you disable that,
and try to see if that fixes the logging.

Syslog on OpenBSD may need something in the chroot to function
properly, perhaps as user root makedev a device node or open a
named-pipe in a directory and then tell syslog to connect to it; or
something along those lines. If it does not have that, then NSD can
call the syslog call, but that routine cannot do anything. Usually
this is performed by the rc.d/nsd startup scripts. These scripts are
OS specific, and I guess the OpenBSD one does not setup the
prerequisites for syslog?

(That script should also setup for: timezone information (for printing
the time to the log), and randomness device (for entropy to see the
secure random generator); but again not all OSes need it because they
use a different implementation for those things).

Best regards,
   Wouter

3

Hi Wouter,

Thanks for your note. After going through my syslog-ng configuration file, I
realized that it was not listening on any socket. Creating a socket
/var/nsd/dev/log solved the issue, even when chroot-ing to "/var/nsd/"

Apart from this, I was wondering if you could help demystifying the log
messages that I get:
host nsd[16191]: NSTATS 1392687148 1392630857 A=71 NS=1 CNAME=5 MX=38 AAAA=32 DNSKEY=5 TYPE251=32 TYPE252=64 TYPE255=85
host nsd[16191]: XSTATS 1392687148 1392630857 RR=0 RNXD=0 RFwdR=0 RDupR=0 RFail=0 RFErr=0 RErr=0 RAXFR=0 RLame=0 ROpts=0 SSysQ=0 SAns=235 SFwdQ=0 SDupQ=0 SErr=0 RQ=333 RIQ=0 RFwdQ=0 RDupQ=0 RTCP=98 SFwdR=0 SFail=89 SFErr=0 SNaAns=0 SNXD=1 RUQ=0 RURQ=0 RUXFR=0 RUUpd=0

Is there a document somewhere explaining the above codes (RR, RDupR etc.)?
Also, I see Sfail=89, sounds like something is wrong?

Thanks again,

Cheers,
cam

4

Those log lines are old school BIND 8 stats lines (deprecated in BIND 9.1.0, I believe). These were very common and alot of people understood the log format and had tools and parsers built over it, so I guess it was a design decision of netlabs to support it in NSD precisely because of this existing understanding in the world.

Specifically, The NSTATS line tells you this: current time, start time of server, then counts of each individual RR type. The XSTATS line tells you more in depth about issues with queries. I believe that almost every stat in the XSTATS that starts with an uppercase R is for a recursive server, and is largely irrelevant for NSD (as NSD is authoritative only). It is just in there for those parsers and tools that I mentioned in the first paragraph (so those tools worked on NSD’s log format out of the box). You can see this in the code for the logging, where many of the stats are hard-coded zero:

	/* XSTATS */
	/* Only print it if we're in the main daemon or have anything to report... */
	if (nsd->server_kind == NSD_SERVER_MAIN
	    >> nsd->st.dropped || nsd->st.raxfr || (nsd->st.qudp + nsd->st.qudp6 - nsd->st.dropped)
	    >> nsd->st.txerr || nsd->st.opcode[OPCODE_QUERY] || nsd->st.opcode[OPCODE_IQUERY]
	    >> nsd->st.wrongzone || nsd->st.ctcp + nsd->st.ctcp6 || nsd->st.rcode[RCODE_SERVFAIL]
	    >> nsd->st.rcode[RCODE_FORMAT] || nsd->st.nona || nsd->st.rcode[RCODE_NXDOMAIN]
	    >> nsd->st.opcode[OPCODE_UPDATE]) {

		log_msg(LOG_INFO, "XSTATS %lld %lu"
			" RR=%lu RNXD=%lu RFwdR=%lu RDupR=%lu RFail=%lu RFErr=%lu RErr=%lu RAXFR=%lu"
			" RLame=%lu ROpts=%lu SSysQ=%lu SAns=%lu SFwdQ=%lu SDupQ=%lu SErr=%lu RQ=%lu"
			" RIQ=%lu RFwdQ=%lu RDupQ=%lu RTCP=%lu SFwdR=%lu SFail=%lu SFErr=%lu SNaAns=%lu"
			" SNXD=%lu RUQ=%lu RURQ=%lu RUXFR=%lu RUUpd=%lu",
			(long long) now, (unsigned long) nsd->st.boot,
			nsd->st.dropped, (unsigned long)0, (unsigned long)0, (unsigned long)0, (unsigned long)0,
			(unsigned long)0, (unsigned long)0, nsd->st.raxfr, (unsigned long)0, (unsigned long)0,
			(unsigned long)0, nsd->st.qudp + nsd->st.qudp6 - nsd->st.dropped, (unsigned long)0,
			(unsigned long)0, nsd->st.txerr,
			nsd->st.opcode[OPCODE_QUERY], nsd->st.opcode[OPCODE_IQUERY], nsd->st.wrongzone,
			(unsigned long)0, nsd->st.ctcp + nsd->st.ctcp6,
			(unsigned long)0, nsd->st.rcode[RCODE_SERVFAIL], nsd->st.rcode[RCODE_FORMAT],
			nsd->st.nona, nsd->st.rcode[RCODE_NXDOMAIN],
			(unsigned long)0, (unsigned long)0, (unsigned long)0, nsd->st.opcode[OPCODE_UPDATE]);
	}

Those variable descriptions are fairly self-explanatory, but here is a link to some in depth descriptions (the last quarter of the page is what you are looking for):
http://docstore.mik.ua/orelly/networking_2ndEd/dns/ch07_06.htm

Cheers,
Will Pressly

5

Also, I believe the SERVFAILs you are seeing are from zones that your server is not authoritative for, more than likely. I believe there is some discussion on this list about amending this behavior (and responding with Refused, if memory serves me correctly, which it rarely does).

Cheers,
Will Pressly

6

Thanks for the informative reply.

About the SERVFAIL, you seem to refer to this thread [1].
Will keep an eye on new releases.

Cheers,
cam

[1] https://open.nlnetlabs.nl/pipermail/nsd-users/2014-January/001780.html

7

It does indeed, a flag is used on the syslogd command line to create
log sockets in chroot jails as necessary. The system rc.d scripts handle
this for daemons such as NSD which are in the base OS; if it's needed for
software in packages, it will be explained by a pkg-readme file or
package installation message.

If users have chosen an alternative syslog daemon (such as Cam has done),
they would be expected to configure it themselves.

8

20.02.2014 04:35, Stuart Henderson пишет:

Syslog on OpenBSD may need something in the chroot to function
properly,

It does indeed, a flag is used on the syslogd command line to create
log sockets in chroot jails as necessary. The system rc.d scripts handle
this for daemons such as NSD which are in the base OS; if it's needed for
software in packages, it will be explained by a pkg-readme file or
package installation message.

Actually most systems have the same issue here and similar solutions.

Usually it is enough to open main system syslog socket (usually /dev/log)
before chroot, and logging will Just Work if syslogd is not restarted.
Only for the latter case one (usually) needs additional configuration
on the syslogd part, to create various additional sockets in various
chroot jails.

Is OpenBSD different in this aspect? Will main /dev/log (or equivalent)
opened before chroot work after chroot, provided that syslogd is not
restarted?

Thanks,

/mjt