Bug 688 - NSD does not log successful AXFR
NSD does not log successful AXFR
Product: NSD
Classification: Unclassified
Component: NSD Code
Other FreeBSD
: P5 normal
Assigned To: NSD team
Depends on:
  Show dependency treegraph
Reported: 2015-07-20 11:40 CEST by jeroen
Modified: 2015-07-20 12:50 CEST (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description jeroen 2015-07-20 11:40:57 CEST
I am currently having an issue with possible unsuccessful AXFR attempts, and I would like to debug the issue. Unfortunately NSD does not seem to be able to log successful AXFR transfers to its slave servers.

According to the documentation, it can log successful AXFR attempts to other servers, it can log AXFR refusals, but it can not log successful AXFR requests from other servers, which seems a bit strange to me.

       verbosity: <level>
              This  value  specifies  the verbosity level for (non-debug) log-
              ging.  Default is 0. 1 gives  more  information  about  incoming
              notifies  and  zone  transfers.  2  lists soft warnings that are

              Verbosity 0 will print warnings and  errors,  and  other  events
              that are important to keep NSD running.

              Verbosity  1 prints additionally messages of interest.  Success-
              ful notifies, successful incoming zone  transfer  (the  zone  is
              updated),  failed  incoming  zone  transfers or the inability to
              process zone updates.

              Verbosity 2 prints additionally  soft  errors,  like  connection
              resets over TCP.  And notify refusal, and axfr request refusals.
Comment 1 Wouter Wijngaards 2015-07-20 12:50:59 CEST
Hoi Jeroen,

NSD can log it, but in debug log messages.  It then logs:
[..time and pid] nsd: axfr admitted acl [acl that gets transfer].

To enable this you have to configure NSD with --enable-checking,
and pass the flags -F 0x20 -L 1  (or -F -1 -L 2 to get the max debug output, but the previous prints less).

Operators that run authority servers have not asked for this, even though it would be a symmetrical extension of current features.

Best regards,