There are a couple things in urlbar that can start dns connections:
- speculative connections. These are used to warm up the connection before the user visits it, to speed up browsing. We startup a speculative connection when the first urlbar result is received and it's a search or autofill. They can always be disabled setting browser.urlbar.speculativeConnect.enabled to false.
- Single words that are search for, but may actually be local domains, to show the "Did you mean to go to" prompt. There's no pref controlling this, potentially one could be introduced.
If the matter is giving users a way to escape the behavior, we could easily introduce a pref.
If the matter is respecting DOH, I'm not sure I have the knowledge to propose the right fix.
If the matter is stop doing it by default, it would likely break users or make browsing slower.
In our case if we'd stop doing it we wouldn't completely break intranet (at least from Firefox 78 on) because we have nice domain and domain suffix prefs that allow specific entries, and a few very common suffixes are already handled by default. Though we would still break less-technical users trying to access intranet without prior appropriate configuration.
We currently handle it better than Chrome in the sense we don't query if the string contains any of "@:/?#"
We also won't send words that can be recognized as a valid url/origin (depending on PSL, or IP addresses), since we only look for single words that can't be recognized as a valid origin.
My suggestion would be to introduce a pref that allows disabling the dns check for single words behavior (so disable the "Did you mean to go to" bar), so one can set the speculativeConnect pref and this one to prevent any kind of info leaking towards the dns.
We should probably also avoid the dns lookup in PB mode, we don't seem to atm (we do for speculativeConnect).
I'd do those in a dependency.
Then keep this open to keep monitoring what Chrome plans to do; so far I went through their suggestions and we already do some of them, we don't do:
- use history to check if the origin appears somewhere in it
- avoid in case of policies (or provide policy)
- use hosts
Though some of these suggestions appear expensive or non-resolutive.