1540618 - TRR: the first DoH resolution (mode 3) with https://1.1.1.1/dns-query always fails

Status: UNCONFIRMED

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

Description

[David Fifield]

I'm using Firefox Developer Edition 67.0.b6 linux-x86_64 en-US.

Create a new profile using firefox --ProfileManager. Create a user.js file with the following contents. The top portion disables background network activity (updates, safebrowsing, activity streams, etc.) so the browser is completely network-silent at startup. The bottom portion enables TRR with the 1.1.1.1 resolver in mode 3.

user_pref("app.normandy.enabled", false);
user_pref("app.update.auto", false);
user_pref("app.update.checkInstallTime", false);
user_pref("app.update.interval", 999999999);
user_pref("browser.laterrun.enabled", false);
user_pref("browser.newtabpage.activity-stream.disableSnippets", true);
user_pref("browser.newtabpage.activity-stream.discoverystream.endpoints", "");
user_pref("browser.newtabpage.activity-stream.enabled", false);
user_pref("browser.newtabpage.activity-stream.feeds.section.highlights", false);
user_pref("browser.newtabpage.activity-stream.feeds.section.topstories", false);
user_pref("browser.newtabpage.activity-stream.feeds.snippets", false);
user_pref("browser.newtabpage.activity-stream.feeds.topsites", false);
user_pref("browser.newtabpage.enabled", false);
user_pref("browser.safebrowsing.blockedURIs.enabled", false);
user_pref("browser.safebrowsing.downloads.enabled", false);
user_pref("browser.safebrowsing.malware.enabled", false);
user_pref("browser.safebrowsing.passwords.enabled", false);
user_pref("browser.safebrowsing.phishing.enabled", false);
user_pref("browser.safebrowsing.provider.mozilla.gethashURL", "");
user_pref("browser.safebrowsing.provider.mozilla.updateURL", "");
user_pref("browser.search.geoip.url", "");
user_pref("browser.search.geoSpecificDefaults", false);
user_pref("browser.search.suggest.enabled", false);
user_pref("browser.shell.checkDefaultBrowser", false);
user_pref("browser.startup.firstrunSkipsHomepage", false);
user_pref("browser.startup.homepage", "about:blank");
user_pref("datareporting.healthreport.uploadEnabled", false);
user_pref("datareporting.policy.dataSubmissionEnabled", false);
user_pref("dom.push.enabled", false);
user_pref("extensions.pocket.enabled", false);
user_pref("geo.enabled", false);
user_pref("geo.wifi.url", "");
user_pref("network.captive-portal-service.enabled", false);
user_pref("privacy.trackingprotection.enabled", false);
user_pref("privacy.trackingprotection.pbmode.enabled", false);
user_pref("startup.homepage_override_url", "");
user_pref("startup.homepage_welcome_url", "");
user_pref("toolkit.telemetry.enabled", false);

user_pref("network.trr.mode", 3);
user_pref("network.trr.uri", "https://1.1.1.1/dns-query");

Go to about:networking#dnslookuptool and enter "example.com" or any domain.

1. The first time you click "Resolve", there is no result and the terminal output is
   JavaScript error: chrome://global/content/aboutNetworking.js, line 458: NS_ERROR_UNKNOWN_HOST: Component returned failure code: 0x804b001e (NS_ERROR_UNKNOWN_HOST) [nsIDashboard.requestDNSLookup]
   The terminal output appears well within network.trr.request-timeout.
2. The second and subsequent times you click "Resolve" (for the same name or any other name), the resolution works and IP addresses are displayed. This state persists until the browser is restarted, at which point the first name resolution will again fail.

In place of 1.1.1.1, I tried using mozilla.cloudflare-dns.com with a bootstrap IP address. I did not experience the error in this case: the first name resolution works.

user_pref("network.trr.uri", "https://mozilla.cloudflare-dns.com/dns-query");
user_pref("network.trr.bootstrapAddress", "104.16.248.249");

And it seems that network.trr.bootstrapAddress being set prevents the problem from occurring, even if network.trr.uri contains an IP address. After setting network.trr.bootstrapAddress, you have to go back to about:config and unset it again, for the problem to start happening again. In other words, the following configuration does not exhibit the problem:

user_pref("network.trr.uri", "https://1.1.1.1/dns-query");
user_pref("network.trr.bootstrapAddress", "104.16.248.249");

It also affects normal browsing through the URL bar, but you have to be careful to avoid creating any background name resolutions. Typing "https://example.com/" in the URL bar gives "Hmm. We’re having trouble finding that site." the first time, but works the second and later times. But even just typing "https://w" causes the URL bar to do a name resolution in the background (you can see the POST https://1.1.1.1/dns.query in the browser console), and the subsequent navigation will work. I found testing with about:networking#dnslookuptool to be more robust.

I noticed this while trying to get a packet capture of a DoH-using extension's network activity, separate from all other background browser activity (which is why I had the big user.js file turning features off). The extension's first request would always fail. I couldn't figure out how to get the browser console to log HTTP responses, so I wasn't able to inspect the first DNS reply to see what might have gone wrong.