I think I brought this up several years ago...
I'd love to see basic logging support in nsd. Namely, the use of
syslog calls to facilitate logging of basic data (request IP, query
type, host name if any), especially for FAILED queries (ones that are
NXDOMAIN). Looking at a log of failed queries tells you a lot about
possible configuration errors (especially if migrating) and provides
valuable insight into possible security issues (probes, etc).
-Lew Payne
Hi Lew,
You may already have considered this, but:
tcpdump -vv udp port 53 and "udp[11] & 0xf == 3"
which prints out all nxdomains passing the server,
this is not good enough for that purpose?
Best regards,
Wouter
If the interface is left in promiscuous mode continuously, there
are a few things to be aware of.
1) The NIC must process more traffic, sometimes more than the
host can handle. On an underpowered host, services may suffer
due to CPU saturation or packet loss at the congested NIC;
2) The host is exposed to attacks against the pcap library code;
3) The host is exposed to a small number of attacks aimed at
services listening on addresses of other machines;
4) The admin(s) of the host will no longer have a sure-fire way
to know if an intruder has managed to start a network sniffer;
5) Some latency is added to the processing of packets on the
promiscuous interface;
Also, tcpdump has only rudimentary output capabilities for tallying/
logging the capture of specific traffic by expression. Pcap files
sometimes require a great deal of post-processing to extract the
kind of data that you typically find in an application log file.
It would be nice, as Lew pointed out, to add a small amount of code
to nsd at the point where the NXDOMAIN decision is made to allow
writing a line to a dedicated logging API like syslog, or to a simple
logfile specified at runtime.
Any additional functionality should not be on the fast code path
for valid replies. The logging can happen after the negative reply
is sent. Logging and file access APIs that use asynchronous I/O
should be used instead of those that block.
Best regards,
Greg
tcpdump can be used without promiscuous mode though.
Back to the original topic, if logging was desirable, using shared
memory and a separate gathering process is likely a much better idea.
Joerg
Some SYS-V shared-memory calls, and a very small circular buffer would
be fine. You could make the data available, and leave it up to us to
extract it or write a simple logger if you're feeling generous. If
you included a simple one or two byte incrementing counter at the head
of each entry, we could easily detect screw-ups on our part (failure
to read buffer before wrap-around), as well as easily determine old
data from new.
That's assuming you don't want to use async calls and log to a file
(in which case you just abandon failed writes... which would be fine,
also).
It would certainly be better than the problems posed by running
tcpdump, especially in a production environment.
Hint - For years, I've been using log data (HTTP requests for
nonexistent pages or domains, SMTP requests for nonexistent users,
IMAP and POP3 requests for nonexistent users, etc, etc) to firewall
malicious probes. The only thing not protected, since switching from
bind to nsd, has been the DNS servers due to lack of adequate logging
facilities. The performance, ease of use, reliability and security of
nsd has vastly outweighed the logging issue. However, it would serve
as a crowning touch.
-Lew Payne
You don't have to use tcpdump.
There are tools like dnscap:
https://www.dns-oarc.net/tools/dnscap
There will be always "something" you need to add to logging and I am
perfectly fine with nsd not having complicated logging capabilities,
if there are other tools which can be used, without any problems.
Whole DITL (http://www.caida.org/projects/ditl/) was accomplished by
using dnscap, so I don't see why it couldn't be used for what you ask
for.
Ondrej.
Ondrej - The reason I can't use dnscap is because, until you made
mention of it, I didn't know it existed. I've been out of the loop of
daily technical life for many years now, and in "maintenance" mode.
That's why there are conversations like this one, where someone more
current on open source tools ends up teaching an old dog like me new
tricks (I hope the gist of the expression isn't lost in translation).
Thank you for bringing this to our collective attention. I see dnscap
uses bpf, which should be compatible with FreeBSD. I'll have to give
it a try.
-Lew Payne
Even more importantly than all of those things, looking at the traffic
passed on one or all interfaces does not show us how the application
(NSD in this case of course) interpreted the requests and responded to
them, etc.
Query logging that could be toggled on and off at runtime with some sort
of external signal would be quite valuable for all kinds of diagnostic
use. Logging of responses would also be useful.
It would be very nice to have such logging implemented in an efficient
and non-intrusive way, but I think if the control test is done carefully
enough that when off it had negligible impact then even including
logging within performance critical sections would be quite useful for
diagnostic purposes.