> 1305735623.373659 internal error: NB-DNS error in DNS_Mgr::Process
> (ns_initparse(): Message too long)
...
Question for Robin/Vern/whomever, should this really be calling internal_error?
No, it shouldn't. I suspect the problem is that nb_dns is returning an
internal error and the caller lacks enough specifics to understand whether
it represents something fatal or just means "forget about the current
lookup".
Vern
I suppose the more direct question is, are there any times where values returned from nb_dns_activity being less than 0 would represent a fatal error?
Offhand I can't think of any unless that same code path is used when doing remote Bro connections. Any other time (I think) it would represent some sort of analysis-based lookup in which I would rather Bro keeps running than completely failing.
.Seth
I suppose the more direct question is, are there any times where values returned from nb_dns_activity being less than 0 would represent a fatal error?
IIRC, it's used by Bro at startup to resolve hostnames in the policy
scripts. If those fail to resolve due to a serious problem (rather than
just the name not existing), then arguably Bro is about to run with
fundamentally incorrect/missing information, which is not very safe.
That said, whether it should bomb out under such circumstances is
still debatable.
Vern
IIRC, it's used by Bro at startup to resolve hostnames in the policy
scripts. If those fail to resolve due to a serious problem (rather than
just the name not existing), then arguably Bro is about to run with
fundamentally incorrect/missing information, which is not very safe.
Agreed, but I would consider it a fairly minimal risk due to such extremely limited use of that feature anyway. In the scripts I've been working on, I haven't even used it at all so the risk is even lower.
That said, whether it should bomb out under such circumstances is
still debatable.
I agree. If I get a chance soon I'll commit a change to fastpath changing those to runtime warnings instead of internal errors. Unless... Jon, would you like to do it?
.Seth
> IIRC, it's used by Bro at startup to resolve hostnames in the policy
> scripts ...> Agreed, but I would consider it a fairly minimal risk due to such extremely
limited use of that feature anyway. In the scripts I've been working on,
I haven't even used it at all so the risk is even lower.
? You don't have things like tables of sensitive systems that are listed
using hostnames rather than addresses? This strikes me as a pretty basic
use case.
Vern
I agree. If I get a chance soon I'll commit a change to fastpath
changing those to runtime warnings instead of internal errors.
Unless... Jon, would you like to do it?
Maybe start a new ticket for this and continue any discussion there; the DNS-related issues in this thread are separate from what I was originally asking about. Then we'll just see who claims ownership of the ticket first.
- Jon
Good point. Done.
.Seth
IIRC, it's used by Bro at startup to resolve hostnames in the policy
scripts. If those fail to resolve due to a serious problem (rather than
just the name not existing), then arguably Bro is about to run with
fundamentally incorrect/missing information, which is not very safe.Agreed, but I would consider it a fairly minimal risk due to such extremely limited use of that feature anyway. In the scripts I've been working on, I haven't even used it at all so the risk is even lower.
How about triggering an event on such failure conditions (perhaps
sending the hostname)? - each site could then determine globally or by
hostname how to deal with this situation
I think you may lose too much context about the initial lookup by that point. If it was a statically defined hostname in a script (that was really important) and it failed, what would you decide to do? You'd have to know the variable that it was supposed to be assigned to after being looked up if you wanted to try the lookup again. I don't think you'd ever want to kill Bro, but you'd probably want it logged which would already be taken care of by the runtime error.
Perhaps you're right though in that if there is some *really* important domain name, you would have some recourse to make sure that name is looked up.
.Seth