1452616 - TRR: DoH doesn't seem to work on Android

Status: RESOLVED FIXED

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

Description

[CraigT]

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:

about:config
network.trr.mode = 2
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query

Browse to www.bbc.co.uk or another sites known to produce valid doh responses via 'https://mozilla.cloudflare-dns.com/dns-query'


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.

Comment 1

[CraigT]

Android version tested: 8.1.0

Comment 2

[CraigT]

Additionally: I have tested this via cellular and WiFi to rule out filtering etc. The above results are consistent across networks.

Comment 3

[Daniel Stenberg [:bagder]]

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.

Comment 4

[CraigT]

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?

Comment 5

[Daniel Stenberg [:bagder]]

Yay, awesome. Thanks for confirming this Craig!

I'll reverse the default for Android.

Comment 6

[Daniel Stenberg [:bagder]]

Attachment: bug 1452616 - make TRR not wait for captive portal on Android by default

Review commit: https://reviewboard.mozilla.org/r/236260/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/236260/

Comment 7

[Patrick McManus [:mcmanus]]

Comment on attachment 8967578 [details]
bug 1452616 - make TRR not wait for captive portal on Android by default

https://reviewboard.mozilla.org/r/236260/#review242048

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)

Comment 8

[Daniel Stenberg [:bagder]]

The CP issue is now Bug 1453891.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5b0c886b11cd
make TRR not wait for captive portal on Android by default r=mcmanus

Comment 10

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/mozilla-central/rev/5b0c886b11cd