From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 BuildID: About the DNS resolve, suppose the following case: 1. there are some (more than one) IP addresses which are mapped to the same host name 2. only some of them is available 3. and only one is the true IP address 4. maybe this depands on what protocol we use... We should try each IP adress until we find one which works and then remember that returned address. Should try them all but add an API to say "return only this IP address entry next time we ask" then we return all addresses until we make a choice for some reason. That would be sufficient for both requirements: 1. Avoid DNS spoofinng 2. Get a IP address which works Note that we may want to cache these results per IP-address+protocol and not only per IP-address. Any comments? Reproducible: Always Steps to Reproduce: 1. refer to http://bugzilla.mozilla.org/show_bug.cgi?id=108108 2. refer to http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&selm=3D4EC290.6080508%40netscape.com Actual Results: While connecting to a host, mozilla only try 1 IP address. nsSocketTransport::Process in case eSocketState_WaitDNS ->nsSocketTransport::doResolveHost *** here we use "mNetAddrList.Init(1);" *** ->nsSocketTransportService::LookupHost (or lookup in cached dns service) in case eSocketState_WaitConnect ->nsSocketTransport::doConnection if failed ->nsSocketTransport::OnConnectionFailed ->mNetAddrList.GetNext(mNetAddress) *** how can we GetNext here??? ***

after talking on IRC with roland for a bit, i'm thinking that at the very least we should index our hashtable by host:port instead of just host, since different services may be hosted by different ip-nodes under the same FQDN. this is apparently actually quite common. i should probably file a different bug for the change i'm talking about... this one should perhaps stay as a RFE as Roland intended.

Just two examples for the problem: 1. A machine may have a IPv6 address but the IMap server running on it only works over IPv4 (not everything is IPv6-enabled... welcome to real life in the IPv6-world... =:-) 2. A similar issue may occur when multiple machines share one hostname: One hostname, multiple IP addresses with multiple services, but one service may be only available for a subset of these IP-addresses (for example one server process may be offline for maintaince on one box) Therfore I propose to move the issue out of necko and let the single modules handle the details, e.g. the single modules in mozilla should be able to obtain all IP addresses and have an API to tell the necko layer: "This IP entry is good, return only this one the next time I ask".

cc'ing dougt, dveditz, mstoltz... this bug is fallout from the princeton patch. we basically break people who host say HTTP on IPv6 and IMAP on IPv4 all with the same hostname. ouch!

calvin: how critical is this for sun? we are close to wrapping up moz 1.1, and it'd be nice to have some idea about the severity of this bug. thx!

-> me

simple patch.

Comment on attachment 94662 [details] [diff] [review] v1 patch r=mstoltz.

Do we really want to go this way? I guess it would work with JS security which uses scheme/host/port, but we know there are other parts of the product with looser matching (scheme/host, for example, or just host). Would it be possible to store both a v4 and a v6 address for each host, using an unset value as necessary? That'd make each table entry a little bigger, but less than duplicating the host name. How common are multiple ports? I suspect an extra v6 address would take up less room than repeating the host name for each port, and would block anyone who tries to get around the pinning by shuffling things from port to port.

Comment on attachment 94662 [details] [diff] [review] v1 patch sr=dveditz (with minor worries about memory bloat)

fixed-on-trunk

I'd like to verify this, but I'm not sure how the behavior has changed.

Bring up two hosts on two different IP addresses. One host supports protocol A, another supports protocol B. Create a DNS name which has two address records, one for each host. Without this fix, only one of the two protocols would be accessible within the cache timeout. With the fix, both protocols will be accessible.

mass remove verifyme requests greater than 4 months old