logging query results

[Kevin Darcy]

Bill Larson wrote:
> JINMEI Tatuya / $B?@L at C#:H(B <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