TRR: DoH doesn't seem to work on Android

RESOLVED FIXED in Firefox 61



Last year
Last year


(Reporter: c, Assigned: bagder)


61 Branch

Firefox Tracking Flags

(firefox61 fixed)


(Whiteboard: [necko-triaged][trr])


(1 attachment)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180409100035

Steps to reproduce:

network.trr.mode = 2
network.trr.uri =

Browse to or another sites known to produce valid doh responses via ''

Actual results:

No hostnames ever report trr 'true' on Android, about:networking#dns

I have validated several hostnames on the MacOS version of FF nightly, with an identical configuration, these report true.

Expected results:

TRR true is expected in on various DNS lookups.
Whiteboard: [trr]
Android version tested: 8.1.0
Additionally: I have tested this via cellular and WiFi to rule out filtering etc. The above results are consistent across networks.
Assignee: nobody → daniel
Component: General → Networking: DNS
Priority: -- → P1
Product: Firefox for Android → Core
Whiteboard: [trr] → [necko-triaged][trr]
Version: Firefox 61 → 61 Branch
Valentin pointed out to me that our captive-portal detection isn't used on Android (since it is handled by the OS itself) which makes the "CP clear" signal never arrive and TRR will never start.

Setting network.trr.wait-for-portal to false should thus be enough to get TRR working on Android.
I can confirm this is now working, and with similar behaviour to the desktop. Should the default for the Android version toggle differ from desktop as a result of the above statement?
Yay, awesome. Thanks for confirming this Craig!

I'll reverse the default for Android.
Comment on attachment 8967578 [details]
bug 1452616 - make TRR not wait for captive portal on Android by default

to recap the out of band conversation, this means that trr won't work on android in captive portal situations (because it won't retry as its waiting for the cp signal that never comes).. can we open a bug on that? (it might be able to be resolved by just noticing working https from any source)
Attachment #8967578 - Flags: review?(mcmanus) → review+
The CP issue is now Bug 1453891.
Pushed by
make TRR not wait for captive portal on Android by default r=mcmanus
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
You need to log in before you can comment on or make changes to this bug.