[Decentralized DNS] This site can't be reached error page is shown after opt-in to Unstoppable Domains or ENS from the interstitial page before the actual page is loaded

[yrliou]

Description

This site can't be reached error page is shown after opt-in to Unstoppable Domains or ENS from the interstitial page before the actual page is loaded.

Steps to Reproduce

1. Open Brave using a fresh profile folder.
2. Enable Decentralized DNS feature flag if needed.
3. Visit brave.crypto and choose Proceed.

Actual result:

Above error page is shown, then the page loaded normally after a bit.

Expected result:

Should not see the error page.

Reproduces how often:

Easily, like 80% chances

Brave version (brave://version info)

Version/Channel Information:

• Can you reproduce this issue with the current release?
• Can you reproduce this issue with the beta channel?
• Can you reproduce this issue with the nightly channel?

Other Additional Information:

• Does the issue resolve itself when disabling Brave Shields?
• Does the issue resolve itself when disabling Brave Rewards?
• Is the issue reproducible on the latest version of Chrome?

Miscellaneous Information:

cc @bbondy

[yrliou]

Looks like the error page come from a previous cached page result.

[bbondy]

@yrliou can you invalidate the cache when the option is flipped or bypass the cache or something along those lines?

[yrliou]

@bbondy I was wrong before, it is not the cached result.
The DNS error actually came from the result of trying to resolve this using non-secure DNS server.
When we update network service with added UD/ENS resolver, probe requests to these servers will be triggered.
Before probe requests are completed & successful, chromium will fallback to non-secure DNS first since it doesn't know the server availability yet. (https://source.chromium.org/chromium/chromium/src/+/master:net/dns/host_resolver_manager.cc;l=3148-3154;drc=8c1c8ec9bdb2d084a0e2224fbdac083e4ffb9d33;bpv=1;bpt=1)
This is why we will see the error page at first, cuz probe requests are not done yet and it's not using the added UD/ENS resolver to do the resolution.

Might be able to avoid this behavior by overriding ResolveContext::GetDohServerAvailability and ResolveContext::NumAvailableDohServers and make exceptions to return UD/ENS resolvers as available before first probe is completed.

[yrliou]

Just a note that brave/brave-core#8212 addressed the most easy to reproduce case that users are easy to get error when they first opt-in due to the first probe is not completed yet.
We still can see this error page if for some reason we get error from the resolver or there's probe failure.

[stephendonner]

Verified FIXED using nightly with the inline testcase here, on build

Brave	1.23.36 Chromium: 89.0.4389.86 (Official Build) nightly (x86_64)
Revision	0c2dac31bc21e806a791641316e99920f84ea52c-refs/branch-heads/4389@{#1472}
OS	macOS Version 11.2.3 (Build 20D91)

I remember being able to reproduce and easily see this with previous trunk builds, while testing Decentralized-DNS support (it was a "flash," long enough to notice, however).

I tried 15 times to reproduce the bug, and cannot, any longer 👍