logging query results

[wes]

On Tue, Dec 2, 2008 at 4:28 PM, Kevin Darcy <kcd at chrysler.com> wrote:

> Bill Larson wrote:
>
>> JINMEI Tatuya / 神明達哉 <Jinmei_Tatuya at isc.org> said:
>>
>>
>>
>>> At Fri, 28 Nov 2008 10:08:34 -0800,
>>> wes <bind at the-wes.com> 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
>
>
I see no reason we can't have it both ways. There are 4 main concerns that I
see being brought up:

1) Performance
2) Security
3) Code clutter
4) Redundancy/Duplication of effort/Reinventing the  wheel

My thoughts:

1) Performance should not be an issue if it is implemented correctly. This
means making the debugging statements optional, and even perhaps offering a
flag to remove them entirely at compile time. This does not currently seem
to be an option, but it could be added by those that are interested in
seeing it. My understanding is that this should not be difficult.

2) Security is always at least somewhat of a concern. You never know when
the next vulnerability will be discovered. Extra logging can only help us
find those vulnerabilities, which we want to fix. Besides, is it still a
concern if it's turned off? I would imagine a majority of users won't even
enable logging beyond the most basic defaults, and those who do have a
reason for doing so (like me). They would/should then disable it again when
that reason is no longer pressing. Or, again, if it's a major concern, it
can be compiled right out from the start. I am a big proponent of giving
people enough rope to hang themselves; they are just as likely to use it to
climb their way out of a ravine.

3) I can't argue too much with this one, save that I believe it's worth it.
Again, if it's a concern, it can be grepped out or silenced by your IDE of
choice.

4) I think that logging is one area that can afford a little redundancy, or
maybe even a lot of it. As Kevin noted, dnscap still has plenty of uses. But
if we can get Bind to do the same job internally, it can only make us poor
sysadmins' lives that much easier. Case in point, I tried to compile dnscap
today, and it is missing some header files, which I'm apparently supposed to
grab from the Bind source. I installed Bind from a package manager, thus I
do not have the source. I will have to go download it, find the files I
need, somehow tell dnscap where they are, etc, etc. I'm not saying it's not
possible, but it is a non-trivial time investment. Plus the time I spent
trying to get Bind's internal logging routines to do what I wanted, only to
later discover that it is not possible. Now we're looking at a burden on any
admin who wants to do this.

In conclusion, I think we would gain more than we lose.

Thank you for reading.

-wes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20081202/eafa1f83/attachment.html>