161228 - socket transport DNS cache should map host:port -> ipaddress instead of host -> ipaddress [was: RFE for new API for DNS resolve]

Status: RESOLVED FIXED

(Core :: Networking, defect, P2)

Description

[Calvin Liu]

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??? ***

Comment 1

[Darin Fisher]

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.

Comment 2

[Roland Mainz]

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".

Comment 3

[Darin Fisher]

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!

Comment 4

[Darin Fisher]

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!

Comment 5

[Darin Fisher]

-> me

Comment 6

[Darin Fisher]

Attachment: v1 patch

simple patch.

Comment 7

[Mitchell Stoltz (not reading bugmail)]

Comment on attachment 94662 [details] [diff] [review]
v1 patch

r=mstoltz.

Comment 8

[Daniel Veditz [:dveditz]]

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 9

[Daniel Veditz [:dveditz]]

Comment on attachment 94662 [details] [diff] [review]
v1 patch

sr=dveditz (with minor worries about memory bloat)

Comment 10

[Darin Fisher]

fixed-on-trunk

Comment 11

[benc]

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

Comment 12

[John G. Myers]

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.

Comment 13

[Tracy Walker [:tracy]]

mass remove verifyme requests greater than 4 months old