1890640 - Invalid reuse of connections between different IP stacks

Status: RESOLVED DUPLICATE of bug 1420777

(Core :: Networking, defect)

Description

[Yegor]

Attachment: wrong_reuse.JPG

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36

Steps to reproduce:

We have a Network Status page that conducts all kinds of tests related to our DNS platform: https://controld.com/status

We fetch multiple endpoints with JavaScript, from several TLDs and most importantly, several subdomains on the same TLD.

The issue arises with single stack endpoints that are meant to detect both your IPv4 and IPv6 addresses:

https://api-v4.controld.com/ip (has only A record)
https://api-v6.controld.com/ip (has only AAAA record)

Above endpoints share the same TLS cert, however these ones do not (but behave the same):

https://cachebreaker.ipv4.controld.io/ip
https://cachebreaker.ipv6.controld.io/ip

Actual results:

In Firefox (and no other browser), the connection is reused between 2 of the above endpoints. See attached image.

In this example, notice api-v4.controld.com is "resolved" to an IPv6 address, but this subdomain has no AAAA records.

Same happens in reverse, on IPv4 only networks.

Opening the above URLs in separate tabs behaves as expected.

Expected results:

Connection should not have been reused, since these are different subdomains which operate on different IP stacks.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Ed Guloien [:edgul]]

I didn't have any luck reproducing this issue (on linux). I tried the following:

• navigated to the above sites and checked the ips in devtools
• navigated to example.com and fetched the above sites from console
• navigated to controld.com and fetched the above sites from console
• opened a simple html file with the contents <script> fetch("https://api-v4.controld.com/ip"); fetch("https://api-v6.controld.com/ip"); </script>
• all of the above with network.dnsCacheEntries set to 0
• all of the above with private browsing window

Or is there a better way to elicit this? If not, we will need some http logs on this. I recommend using about:logging, logging to a file and emailing the log to [e-mail]. The default log string should be good as it contains DNS logging nsHostResolver.

Thanks!

Comment 3

[Yegor]

I'm unable to reproduce using your simple script either, but can reproduce on the status page in all OSes, Ubuntu 22 included, and in console.

6 fetch requests via console: https://i.imgur.com/dWzBUL8.jpeg
network tab after that: https://i.imgur.com/6GAmBfz.jpeg

This doesn't seem to happen every time either, and it eventually "fixes itself", but restarting the browser makes it reproducible.

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

Since you can reproduce this with your status page, can you get logs via about:logging and send them to [e-mail]? (see comment 2 for links). With those we should be able to track this down.

Thanks!!

Comment 5

[Yegor]

All done, log sent to [e-mail]

Thanks!

Comment 6

[Yegor]

Hmm, email bounced.

---

Your message wasn't delivered to [e-mail] because the address couldn't be found, or is unable to receive mail.

The response was:
The email account that you tried to reach does not exist. Please try double-checking the recipient's email address for typos or unnecessary spaces. For more information, go to https://support.google.com/mail/?p=NoSuchUser

Is it [e-mail] or [e-mail]? I just emailed .com, that didn't seem to bounce.

Comment 7

[Valentin Gosu [:valentin] (he/him)]

I think this is bug 1420777 which was recently fixed.
Could you try again with a nightly build? https://nightly.mozilla.org
Let us know if you're still seeing this issue. Thanks!

Comment 8

[Yegor]

Cannot reproduce issue in the nightly build 126.0a1. Did this fix already make it into the Developer Edition 125.0b9 as I can't reproduce it there either.

Can only reliably reproduce in release 124.0.2.

Comment 9

[Randell Jesup [:jesup] (needinfo me)]

Bug 1420777 is only fixed in 126 or later, so dev ed 125 wouldn't have it.