From: Kevin Darcy <[EMAIL PROTECTED]>
Subject: Re: logging query results
To: [EMAIL PROTECTED]
Date: Wednesday, December 3, 2008, 1:28 PM
Bill Larson wrote:
JINMEI Tatuya / 神明達哉
<[EMAIL PROTECTED]> said:
At Fri, 28 Nov 2008 10:08:34 -0800,
wes <[EMAIL PROTECTED]> wrote:
I would like to know if it's possible to
log the output of each dns query.
Do you mean the response to each query by
"output"?
If so, there's currently no such log messages
regardless of log level.
We may implement it in the future as we discussed
in a different thread:
https://lists.isc.org/pipermail/bind-users/2008-December/073981.html
Is anyone besides myself beginning to feel that too
MUCH functionality is being built into BIND? Will the next
request be to put out the cat before bedtime?
I'm concerned that BIND is being made too complex,
with the associated security issues of any complex system.
Sendmail is a perfect example of this. It tried to do
everything with the resulting "bug of the month"
outcome.
Query logging is a great idea, but OARC has already
produced a very functional "dnscap" which will
capture all DNS traffic, queries and responses, incoming and
outgoing. Maybe this type of logging functionality could be
better relegated to a third party tool such as
"dnscap" rather than being built directly into
BIND.
Adding functionality for for the purpose of better
operations is one thing. Including the capability of
performing zone transfers inside BIND was a great addition
rather than having a separate "named-xfer" tool.
This made running in a chroot environment much simpler,
easier, and secure. This is "good" additional
functionality.
Additional functionality, such as adding additional
query logging capabilities that aren't critical to the
operation of the basic system, simply increase complexity
with the inherent decrease in security that makes this type
of addition a drawback.
Please, keep BIND as simple as possible (but not
simpler). Leave additional capabilities to separate tools
such as "dnscap".
Bill,
While I appreciate the work that's gone into dnscap
(which I use), looking at the big picture, does it really
make sense to have a *separate* tool, just for the purpose
of dumping the contents of DNS packets coming into, or
leaving, a particular instance of named, in a human-readable
form? From the standpoint of efficiency, named already has
intimate details about the contents of every packet it
processes, all that remains is that it render those contents
into a human-readable form into a logfile.
If dnscap is run outside of named, however, it needs to
capture the packets in wire-format from the raw device --
requiring, usually, superuser privileges, which opens up
some security issues -- and then parse those packets from
scratch, using much of the same logic, the same algorithms,
that named itself uses. Seems like a duplication of effort
to me, and named can do this processing _unprivileged_, if
configured and/or invoked that way, thus allaying your
security concerns.
dnscap certainly has its place as a sophisticated capture
utility on a third-party client (i.e. neither the initiator
or the responder), or on either end, where something other
than BIND, with inferior logging capabilities, is being
used. But if the initiator and/or responder are BIND, why
not leverage all of the algorithms, cpu cycles, etc. that
are already being brought to bear by named to parse the
contents of DNS packets? Yes, it's that dread buzzword
"synergy"; I think we have some here.
Then again, maybe the best of both worlds can be obtained
by having a way for named to simply feed raw packet contents
to some external program, which could be dnscap or something
else. That external program could then filter/format the
packets any way it sees fit...
- Kevin
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
