[Bro] remote.bro problem?

[Ruoming Pang]

>> Ok, I see. The parser looks up the host name by means of
>> DNS_Mgr::LookupHost() which returns a set of IP addresses (because a
>> hostname can correspond to more than one name). But that doesn't
>> match with record's type definition which specifies a single addr,
>> not a set.
>
> Yep, that's exactly the problem.
>
> A better solution would be for hostnames to be of type set[addr] 
> (rather
> than list[addr], which isn't helpful because "list" is strictly an 
> internal
> type - you can't get to it from the policy script level).  I've entered
> this into Mantis, but it's not a trivial fix.

Does the order among returned addresses matter? (If so, perhaps use 
vector[addr]?)

>> Actually, I don't think that giving the host name in the script
>> would help. The address is looked up by the parser, so that in any
>> case the connect() function sees an IP address rather than the name.

It appears that the problem is in the representation of "addr" type 
that the original host name is lost after parsing. Thus one possibility 
is to change the definition of "addr" a little bit: it can be either a 
singleton IP address, or a host name with potentially multiple 
addresses. This is not a trivial change though, as all built-in 
functions on addr's must now handle two possibilities. Another 
possibility is to add another type "host" and allow implicit conversion 
from "addr" values to "host" ones, and in this case, connect() will 
take a "host" type parameter. I think I like the latter approach 
better, as "addr" (as its numeric value) and "host" are really two 
concepts, and our difficulty arises from trying to represent two 
concepts with one type.

Just my $0.02. What do you think?

Ruoming