User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/109.0

Steps to reproduce:

1. Enable "DNS over HTTPS"
2. Open https://www.economist.com/
3. Press "Ctrl + Shift + E" to open Network Monitor
4. Filter URL, "buy.tinypass.com" or "c2.piano.io", and observe connecting address.
5. Observe DNS flags of "buy.tinypass.com" or "c2.piano.io" in the "about:networking#dns" page. (DNS prefetch has been disabled, though has no influence)

Actual results:

POST method (presumably all non GET method) uses IPv6 address, but GET method uses IPv4 address in the meanwhile.

In the "about:networking#dns" page:

buy.tinypass.com ipv4 true
104.17.182.177
104.17.183.177
104.17.184.177
104.17.185.177
104.17.186.177
2606:4700::6811:b6b1
2606:4700::6811:b7b1
2606:4700::6811:b8b1
2606:4700::6811:b9b1
2606:4700::6811:bab1
60 ^partitionKey=%28https%2Ceconomist.com%29 0|0x6001|0|0|

c2.piano.io ipv4 true
104.16.42.65
104.16.240.21
2606:4700::6810:2a41
2606:4700::6810:f015
60 ^partitionKey=%28https%2Ceconomist.com%29 0|0x6001|0|0|

Expected results:

The same domain ought to reuse connection.

Firefox are not racing ipv4 and ipv6 for HTTP/3, according to https://bugzilla.mozilla.org/show_bug.cgi?id=1782716
Hence, the first IPv4 address from HTTPS RR is used.

However, given the definition of DNS extra flags, these domain name resolutions suppress the internal DNS lookup cache, thereby invaliding HTTPS RR, so IPv6 address is used for connection.

I wonder if it is intended or unexpected behavior.

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.

Just so I know I'm looking at the right thing, could you let me know which requests you expect to reuse a connection?
A HAR file, screen recording, etc would be helpful in this regard. Thanks!

POST method connect to a IPv6 address

GET method connect to a IPv4 address

I'm a bit confused here, this POST to buy.tinypass.com has cache-control: no-cache, no-store, must-revalidate in response. Is there a case where we would expect the browser to ignore this?

This issue arose from my personal experiment: Would Firefox access all website via only HTTPS RR without A or AAAA RR, with the benefits of less latency, less DNS queries, HTTPS and HTTP/3 upgrade?
Accordingly, I had written special "DNS over HTTPS" server replying NODATA for A and AAAA RR, and providing HTTPS RR according to A and AAAA RR.

To illustrate how HTTPS RR is synthesized, I take "www.google.com" as an example in the format similar to "about:networking#dnslookuptool" page:

IPs
<empty>
HTTP RRs
1 www.google.com (alpn="h3,h2,http/1.1" ipv4hint="142.250.189.228" ipv6hint="2607:f8b0:4005:80e::2004")

Results:

First, "https://www.google.com/" could be accessed via HTTP/3, and some other websites could be accessed via briefly falling back to HTTP/2 or HTTP/1.1, but certain websites, e.g. "https://www.iana.org", would be accessed after 30 seconds timeout of HTTP/3 connection then falling back to HTTP/1.1.

Second, all third-party non GET HTTP method fails, particularly on Youtube.

Third, after a while, "https://www.google.com/" could not be connected. I think that the culprit is alternative service cache, which is probably related to https://bugzilla.mozilla.org/show_bug.cgi?id=1813355

Last, this would cripple uncloaking canonical names in uBlock because of browser.dns.resolve inability to resolve HTTPS RR https://bugzilla.mozilla.org/show_bug.cgi?id=1778794