logging query results

Wed Dec 3 01:37:41 UTC 2008

ivan jr sy wrote:
> hi all,
>
> what about performance issues? if BIND considers additional logging and DNS admins unwittingly turn ON logging of queries (just by issuing rndc querylog) and other future logging categories, it somehow degrades the performance of BIND.
>
> as i've tested BIND 9.5.0-P2 with authoritative queries, my FreeBSD7 amd64 box can accommodate as much as 34,000 queries per second (i've seen other boxes can go as much as 100,000 QPS), but once logging is turned on, it barely reaches 1,000 queries per second. (for 100,000 qps around 14,000...)
>   
Ideally, some of the logging functions would operate in a separate 
thread, which, on a multiprocessor box, might mean a separate processor 
as well.

Then, it would be pretty much indistinguishable from running a separate 
process (e.g. "dnscap") on the same box, although, admittedly, not as 
good as running dnscap on a totally separate box on the same 
segment/subnet/VLAN...

                        - Kevin

> I hope it is also part of BIND's roadmap, querylog optimization.
>
> fyi on that..
>
>
>
> --- On Wed, 12/3/08, Kevin Darcy <kcd at chrysler.com> wrote:
>
>   
>> From: Kevin Darcy <kcd at chrysler.com>
>> Subject: Re: logging query results
>> To: bind-users at isc.org
>> Date: Wednesday, December 3, 2008, 1:28 PM
>> 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
>>
>> _______________________________________________
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>>     
>
>
>       
>
>
>
>   