1472594 - Requests sent to a wrong host in a DNS round-robin scenario

Status: RESOLVED INVALID

(Core :: Networking, defect)

Description

[mz]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36

Steps to reproduce:

We tried a following DNS scenario
(3 servers with own host names in a domain and a domain with round-robin IN A)

srv1.domain.com IN A IP1
srv2.domain.com IN A IP2
srv3.domain.com IN A IP3
domain.com IN A IP1
domain.com IN A IP2
domain.com IN A IP3

The client connects to domain.com and after a successful login is redirected to the pertaining host. All communication is HTTP/2.



Actual results:

After being redirected to a new host Firefox would send request to the IP picked in round-robin for domain.com rather than host's IP.

For example if round-robin selected IP2 for domain.com and user is redirected to srv3.domain.com Firefox would send https://srv3.domain.com/XXX request to IP2 rather than IP3.

This happens just after Firefox start. Hitting Ctrl+F5 resolves the issue (although Ctrl+R does not). After that all is ok. Confirmed on Win and Linux.

Edge & Chrome had no problem working with the aforementioned scenario.



Expected results:

Connections should be made to redirected host's IP.

Comment 1

[David Olah]

Initially triaging this to core/networking. I'm a bit overwhelmed by the above scenario: Valentin, do you make any heads or tails based on comment 0 scenario?

Comment 2

[Valentin Gosu [:valentin]]

I'm assuming this is just another connection coalescing mixup.
https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/
We've had these kind of bugs before. From what I recall, if there's any overlap of IPs, HTTP/2 will attempt to coalesce those connections. Nick, can you pitch in?

Comment 3

[u408661]

Yes, this sounds very much like http/2 coalescing behaving the way it's supposed to. The only information missing is that the cert presented by domain.com contains the other hostnames in SNI (which is almost certainly the case). I'm going to mark this as INVALID, since this is to be expected. Reporter, please reopen only if the domain.com cert does not also list the srv#.domain.com hostnames in its SNI (which would indicate that there is possibly a bug).

If you wish to force the behaviour you're expecting, you can use the http/2 ORIGIN frame to limit the hosts that will be coalesced on a particular connection, or http status 421 for the misdirected requests.