2058229 - DoH Max Protection no longer resolves private tailnet domains (.ts.net) — worked in earlier Firefox versions

Status: NEW

(Firefox :: Settings UI, defect, P3)

Description

[[:arduoi]]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:152.0) Gecko/20100101 Firefox/152.0

Steps to reproduce:

1. Connected to a Tailscale tailnet with MagicDNS enabled (suffix *.ts.net)
2. In Firefox Settings → Privacy & Security → DNS over HTTPS, selected Custom (Cloudflare and/or ControlD)
3. Navigated to https://<device>.ts.net — a private domain that resolves via Tailscale MagicDNS (system DNS on 100.100.100.100) but not via public DoH providers
4. Observed connection failure

This is on Desktop Firefox, but the same happens on Android Firefox.

Actual results:

Firefox shows: "
Hmm. We’re having trouble finding that site.

Firefox can’t protect your request for this site’s address through our secure DNS provider. Here’s why:
This website wasn’t found by mozilla.cloudflare-dns.com.

Learn more…

You can continue with your default DNS resolver. However, a third-party might be able to see what websites you visit."

The domain is valid — it resolves correctly via system DNS when DoH is disabled/set to Default Protection. Switching DoH to Default Protection immediately resolves the issue.

Expected results:

When a DoH provider returns NXDOMAIN for a domain that the system DNS can resolve, Firefox should attempt system DNS as a fallback, or provide a more descriptive error. This behavior changed in a recent Firefox release — it worked correctly in earlier versions (tested on Firefox 152 range - works).

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Networking: DNS' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[[:arduoi]]

After further investigation, the root cause is clearer:

Recent Firefox releases changed the default state of the "Always warn me if secure DNS isn't available" checkbox in Custom DoH mode. It was previously UNCHECKED by default (silent fallback to system DNS when DoH fails), and is now CHECKED by default (showing an interstitial warning page and blocking the connection instead of falling back).

This means:

• Custom + unchecked (= old default) → silent fallback → works with private tailnet domains
• Custom + checked (= current default) → blocks connection → breaks resolution of private domains

The UI naming is confusing:

• On Desktop, this checkbox controls whether fallback to system DNS is allowed
• On Android, there is NO equivalent checkbox at all. Users cannot configure fallback behavior while keeping DoH enabled. They must choose between Increased Protection (DoH with fallback) or Max Protection (DoH without fallback).

Suggestion: either:
a) Restore the desktop checkbox default to UNCHECKED (old behavior)
b) Add the same fallback toggle option to Android Firefox instead of having increased Protection and Max Protection, making UI discrepancies between desktop/mobile
c) Improve the UI label — "Always warn me if secure DNS isn't available" doesn't clearly communicate that it controls fallback behavior

Comment 3

[Sunil Mayya]

This was added as a part of settings redesign added with Bug 1971428.
Moving this to Settings UI component.

Comment 4

[Mark Striemer [:mstriemer]]

Emma, what do you think of this one?

Comment 5

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1971428

Comment 6

[Emma Zühlcke [:emz]]

It looks like we did change default behavior here. From a security perspective warning the user when DoH is not available rather than falling back to unencrypted DNS is better. Since this is already a "custom" setting I don't think it's too much to ask of users to uncheck that box if they don't want this behavior.

We should not opt users into the checkbox automatically when they upgrade from an older profile. I don't think we do that.

c) Improve the UI label — "Always warn me if secure DNS isn't available" doesn't clearly communicate that it controls fallback behavior

I'm not opposed to updating the copy here, but I don't see how it doesn't already explain exactly what it does. It warns you if secure DNS doesn't work, instead of the silent fallback. What sort of language would you expect instead?

Comment 7

[BugBot [:suhaib / :marco]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:mstriemer, since the bug has recent activity, could you have a look please?

For more information, please visit BugBot documentation.

Comment 8

[Mark Striemer [:mstriemer]]

Emma, do you mind setting priority/severity/Jira if necessary?