[Bro-Dev] dns.bro

[Robin Sommer]

On Tue, May 03, 2011 at 14:13 -0400, you wrote:

> It loads a subset that I believe are a mix between general utility and
> performance.  More consistency would nice, but I'm not exactly sure
> how to get it.  Any ideas?

Not really ... But the problem I see is that it's hard to figure out
what a script is *not* loading and what thus can make sense to add
manually.

How about at least documenting this explicityly for the top-level
script, something like:

    Further scripts that one might one to load in addition are:

        - foo/bar1.bro
            <short description what it does>

        - foo/bar2.bro
            <short description what it does>

> DNS binpac analyzer though (which scares me a bit).  We need to run it
> on live traffic for a while to see how it handles itself.

Ok, let's postone that for the more general analyzer overhaul at some
point. 

> addl responses being passed through or not.  I propose we remove all
> options from the analyzer related to not triggering on auth/addl RRs
> and handle everything at the scripting layer (it's less of a surprise
> that way at least).

Agreed, filed a ticket.

> responses in the logs, but it doesn't currently work because there
> seem to be a bug with the &priority attribute on script layer defined
> and called events.

I've filed a ticket for that as well.

> It's to log responses received for queries (so you can see what a
> query resolved to at that specific time).  I'm not completely happy
> with it yet, but if you run it you can see that it usually logs many
> fewer lines and the total log file size is greatly reduced as well.

I think one thing that confused me was the low timeout of 10secs; I
was expecting something longer, perhaps an hour or so (but then
listing all replies during that interval). But not sure my mental
model on using this data is right.

Also, including a timestamp by default could be helpful?

>  distribution but I liked it because it's a good example of using the
>  logging framework to build a new log.

It definitly is!

> Probably, but I didn't want to suck up too much memory for that
> script.  That's yet another one of those hairy decisions that might
> not work in some high volume situations.

Yeah, but I'd say let's first at least try to do these things "right",
even if more expensive. If it turns out to be a problem, we can still
change it change/optimize later. 

Robin

-- 
Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org
ICSI/LBNL    * Fax   +1 (510) 666-2956 *   www.icir.org