I cannot reproduce it with nightly build, but I can reliably reproduce it with debug build of mozilla central. See this part in the log:

2020-01-22 13:36:10.261154 UTC - [Parent 22744: Socket Thread]: D/nsHostResolver Resolving host [geekflare.com] type 0. [this=0x7fdac4a690e0]
2020-01-22 13:36:10.261174 UTC - [Parent 22744: Socket Thread]: D/nsHostResolver No usable record in cache for host [geekflare.com] type 0.
2020-01-22 13:36:10.261184 UTC - [Parent 22744: Socket Thread]: D/nsHostResolver NameLookup: geekflare.com effectiveTRRmode: 2
2020-01-22 13:36:10.261193 UTC - [Parent 22744: Socket Thread]: D/nsHostResolver TRRService::Enabled MaybeConfirm()
2020-01-22 13:36:10.261199 UTC - [Parent 22744: Socket Thread]: D/nsHostResolver TRRService:MaybeConfirm mode=2, mConfirmer=0x7fda93560000 mConfirmationState=1
2020-01-22 13:36:10.261204 UTC - [Parent 22744: Socket Thread]: D/nsHostResolver TRRService::Enabled mConfirmationState=1 mCaptiveIsPassed=1
2020-01-22 13:36:10.261210 UTC - [Parent 22744: Socket Thread]: D/nsHostResolver TrrLookup:: geekflare.com service not enabled
2020-01-22 13:36:10.261220 UTC - [Parent 22744: Socket Thread]: D/nsSocketTransport after event [this=0x7fda8e77d800 cond=804b001e]
2020-01-22 13:36:10.261226 UTC - [Parent 22744: Socket Thread]: D/nsSocketTransport nsSocketTransport::OnSocketDetached [this=0x7fda8e77d800 cond=804b001e]
2020-01-22 13:36:10.261234 UTC - [Parent 22744: Socket Thread]: D/nsSocketTransport nsSocketTransport::RecoverFromError [this=0x7fda8e77d800 state=0 cond=804b001e]
2020-01-22 13:36:10.261239 UTC - [Parent 22744: Socket Thread]: D/nsSocketTransport not in a recoverable state
2020-01-22 13:36:10.261262 UTC - [Parent 22744: Socket Thread]: D/nsSocketTransport nsSocketInputStream::OnSocketReady [this=0x7fda8e77da98 cond=804b001e]
2020-01-22 13:36:10.261269 UTC - [Parent 22744: Socket Thread]: D/nsSocketTransport nsSocketOutputStream::OnSocketReady [this=0x7fda8e77dad0 cond=804b001e]

Valentin, can you have a look at it?

Nice catch. It seems we gTRRService->Enabled() returns false when mConfirmationState is CONFIRM_TRYING

And nsSocketTransport::mState is STATE_CLOSED instead of STATE_RESOLVING for some reason.

When it's first starting up, when mConfirmationState != CONFIRM_OK
the TRR service is not ready to use.
For TRR_FIRST requests we need to fallback to DNS while the service starts up.

Backed out for multiple perma failures.

Push with failure: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception&revision=fe27999955a41d0de5563ae74158064ca4876718&selectedJob=287086067

Backout: https://hg.mozilla.org/integration/autoland/rev/662cb427df645c16f1b279c08276dc7da704e821

Backed out changeset e051d75e66f7 (bug 1610836) for causing connectivity mass test failures.

Backout revision https://hg.mozilla.org/integration/autoland/rev/791f7108410a0f8a6446b9218af577b772a17605

Failed push https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedJob=287127296&resultStatus=testfailed%2Cbusted%2Cexception&revision=e051d75e66f731651d74d4a5138dd18361d8e260

Failure logs: https://treeherder.mozilla.org/logviewer.html#?job_id=287128199&repo=autoland
https://treeherder.mozilla.org/logviewer.html#?job_id=287128272&repo=autoland

Valentin can you please take a look?

https://hg.mozilla.org/mozilla-central/rev/cd7d8aad0306

Note that for some users in Nightly 74 this could break network connectivity. If you can't access any pages then try going to about:config, and set network.trr.mode to 0. Then update Firefox. That should fix the issue.

Tried reproducing the issue with both an affected normal nightly build and a debug build, but without any success.
@Michal, could you please help out in verifying the issue?

(In reply to Cristian Baica [:cbaica], Release Desktop QA from comment #15)

@Michal, could you please help out in verifying the issue?

I can reproduce the bug with revision c6fcec6a58c9 but cannot with revision cd7d8aad0306, so it's fixed.

Closing the issue as verified based on Michals comment.