Bill Larson wrote:
JINMEI Tatuya / [EMAIL PROTECTED]@C#:H(B <[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
