That's valid, but it's also why HTTP/3 is being pushed for 1-RTT and 0-RTT connections (0-RTT is most likely going to be enabled for their DoH if it isn't already)
The DoH server gets to track users if they use a resumption method, yes. As I understand it Firefox puts extra work in to ensure that it doesn't share the backend cache between your HTTPS service and the DNS resolver so there's no risk that if the DNS service and the HTTPS site you're visiting are owned by the same people they can correlate that, but they would be able to see that it's the same browser asking for say, camelporn.example and visit-arabia.example
If you disabled resumption you could get rid of this issue at a cost of one extra round trip per DNS lookup.
Nobody else gets to track users this way (at least in TLS 1.3 and I'd assume DoH implementers will use TLS 1.3 since they are of similar vintage) because the keys aren't re-used so the identifier for the key will just appear to be random noise each time.
That is resumption. So you still have the overhead for the first connection. Assuming that you don't DNS query every few seconds you are gonna suffer.
On a side note, last I checked Quad9 and Cloudflare (need to recheck that) almost immediateley close the connection once you finished your query. Tested with DoT but the same TLS handshake is required for that.
I think you're confused. You're correct that the first connection is 1-RTT but the resumption is a new connection and is 0-RTT using a resumption PSK.
Let's say your browser was left open when you went to work, you get home, click the bookmark for your preferred porn site, and now the browser needs to resolve the FQDN for that site. How fast is that?
So if you have TCP fast open and 0-RTT TLS 1.3 that's exactly one round trip for your answer, just like traditional unencrypted DNS.
The DNS query gets wrapped as an HTTP request, which gets wrapped as a TLS plaintext, which gets sent as TLS 1.3 early data, which all goes in the Fast Open TCP packet.
The server checks the Fast Open cookie, opens the TCP connection, matches the PSK, unwraps the early data, unwraps the HTTP request, unwraps the DNS query
The server finishes the TLS handshake on the now open TCP connection, and using the now encrypted channel it sends back the HTTP response, which wraps a DNS answer and that goes back as the first TCP packet the other way.
Same number of round trips and packets as for DNS. It's very ugly and QUIC in particular will tidy this up considerably, but it's secure and fast.
Instead of a query coming from an IP (probably NATed with IPv4), you can identify individual browsers AFAICT.