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.
I don't really see what's the right way to solve this. Anyone having
an idea how to handle this?
Well, this has been an ongoing problem. It's tempting to just squash down
single-item lists of addresses to a single address, but that'll bomb when
one fine day the name returns two addresses.
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.
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.
Right.
It seems that there is some additional logic in the communication
code required to check such certificates.
I agree.
Does anybody know if
OpenSSL already provides something along these lines?
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.