2052632 - Occasional incorrect "Server Not Found" errors

Status: RESOLVED FIXED

(Core :: Networking: DNS, defect, P2)

Description

[Jeff Muizelaar [:jrmuizel]]

I've been getting these periodically. I first reported this June 25th but had seen it before then.

Refreshing the page always works.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

RPMGetTRRSkipReason() gives “TRR_OK”

It would be good if there was a way to get more information about what went wrong when the "Server Not Found" page is shown.

Comment 2

[Jeff Muizelaar [:jrmuizel]]

This happened to me again, but for the first time refreshing didn't fix the problem. Clearing the dns cache did.

Comment 3

[Jeff Muizelaar [:jrmuizel]]

This happened again.

Comment 4

[Max Inden]

Thanks for reporting Jeff. Any chance you could do the following whenever you can reproduce again:

1. Take a snapshot of about:networking#dns.
2. Capture a profile with MOZ_LOG=timestamp,sync,nsHostResolver:5,TRR:5,nsHttp:5?

Comment 5

[Kershaw Chang [:kershaw]]

FYI: This could be fixed by bug 2052794.

Comment 6

[Sunil Mayya]

Jeff, please let us know if you still see this issue after the fix lands in nightly in the next few days.

Comment 7

[Kershaw Chang [:kershaw]]

I managed to reproduce this by loading many top sites. When the DoH connection gets closed under load, a single-family
(A-only or AAAA-only) TRR lookup fails transiently, and we end up showing a bogus
"Server Not Found" instead of falling back to native.

Here's the log for www.google.co.jp. The TRR requests are aborted because the HTTP/2
connection closed (0x80470002 = NS_BASE_STREAM_CLOSED):

Http2Session::WriteSegments ... cleanup stream ... returning code 80470002
TRR:OnStopRequest ... www.google.co.jp 1 failed=0 code=80004004   // NS_ERROR_ABORT

We then retry the sibling family, and it comes back with valid data, yet the record
is still finalized as definitive no-address:

TRR Decode: 1 answer records (73 bytes body) www.google.co.jp
TRRQuery::CompleteLookup other request succeeded
status set to NS_ERROR_DEFINITIVE_UNKNOWN_HOST
CompleteLookup: www.google.co.jp has NO address

No resolver=0 line ever shows up, i.e. native fallback never runs.

The cause is in the single-family branch of
TRRQuery::CompleteLookup:
if this family failed and the other family resolved, it sets
NS_ERROR_DEFINITIVE_UNKNOWN_HOST. The guard is just NS_FAILED(status), so a transient
abort is treated the same as a real NODATA. Definitive status then blocks the native
retry in
nsHostResolver::MaybeRetryTRRLookup.

Since these single-family lookups come from Happy Eyeballs racing A and AAAA, I'm adding a
RESOLVE_HAPPY_EYEBALLS flag set on the HE lookups, and skipping the sibling probe and the
definitive upgrade in TRRQuery::CompleteLookup when it's set, so an HE lookup falls back
to native on a transient TRR failure. Non-HE lookups keep the current behavior.

Comment 8

[Kershaw Chang [:kershaw]]

Attachment: Bug 2052632 - Fall back to native when a TRR lookup fails due to a DoH connection error, r=#necko

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/d951c4a19a69
https://hg.mozilla.org/integration/autoland/rev/377d3fc52215
Fall back to native when a TRR lookup fails due to a DoH connection error, r=necko-reviewers,valentin

Comment 10

[agoloman]

https://hg.mozilla.org/mozilla-central/rev/377d3fc52215