My FF just had a DOH brainfart (Solved - user error)
-
I was browsing the net today , and something was fishy ...
Either github.io was unfunctional , or something was wring w. my linux mint ...
github.io answered fine on ping.But i couldn't goto this page in FireFox
https://blog.davehylands.com/capturing-usb-serial-using-wireshark/
I couldn't goto github.io too ....I decided to see if my pfSense had anything to do with that.
Yepp it was blocking DOH, just as i have told it to do (floating rules).
But the strange part is that i have this set in unbound:
# Block FF DoH by defining use-application-dns.net local-zone: "use-application-dns.net" always_nxdomain # # Block DoH Cloudflare - https://forum.netgate.com/post/939705 # JP comment - That is a great solution.. Since you set it static, # unbound will not try to resolve any subdomains of that be it the Mozilla or the chrome one.. local-zone: "cloudflare-dns.com" staticAnd a "host resolve" of the FF canary returns this, just as i told unbound to do.
$ host use-application-dns.net Host use-application-dns.net not found: 3(NXDOMAIN)And i have this set in FF:
FF settings expl.
https://wiki.mozilla.org/Trusted_Recursive_Resolver#network.trr.modeA reboot didn't solve it, github.io was still doing DOH , and therefore unreachable.
I did a wireshark trace, right after reboot + login. Before starting FF.
I was actually expecting it to query the canary domain, but i didn't see that.After poking around in FF about:config wo changing anything.
It went back to normal as in i could browse to the above url wo. using DOH.But what happened ??
I have two different ways of telling FF to NOT use DOH : Canary & browser setting (5)FF writes they might monitor & disable the Canary , if they detect misuse ...
Can anyone else see FF query/reolve the canary ??Have anyone else, with an active DOH blocking system, experienced something like this ?
/Bingo
-
@bingo600 said in My FF just had a DOH brainfart:
Can anyone else see FF query/reolve the canary ??
I just duplicated your test of wireshark and starting FF, flushed my local dns on the box for good measure I did not see any query for the canary.. But if TRR is set to 5, would it?
I then set trr mode to 0.. and repeated test - still not seeing a query for canary.. I even let it run for a while and hit some other sites thinking maybe it doesn't do the query right away on start up.. Curious - I would think it should query for the canary when trr set to 0 maybe.. That is the whole point of canary right? I wonder if it only does that if you set firefox to use doh?
Have to do some digging on when exactly FF would check the canary..
-
But if TRR is set to 5, would it?
Maybe not, but if set to 5 it shouldn't use DOH too ....
No matter what setting of TRR i would have expected it to query the canary before doing ANY DOH.
/Bingo
-
@bingo600 there is some discussion about that in different places - I too interpreted that way, but doesn't seem to actually be the case. From what I can piece together in the few minutes of looking is it will only query that if user set by default to use doh..
My take is there has to be a specific set of circumstances for it to actually query for the canary. I tried the test while I selected to use doh in the firefox network settings while my TRR was set to 0..
I would of thought it would of done a query then - but when it did the query for the uri it defaults to mozilla.cloudflare-dns.com I return 0.0.0.0 via blocking.. in pihole, so pretty sure that tells firefox to fallback to normal dns, and maybe it never does the query for the canary because the doh it tried to use fails..
Would have to maybe disable my blocking of doh domains, and then test if once firefox sees that it can do doh, does it then look for the canary to see if the network admins have set it it not too..
-
@johnpoz said in My FF just had a DOH brainfart:
mozilla.cloudflare-dns.com
Maybe i should block that too
My linux doesn't use my PiHole , only Phone & MMedia Vlan does
Ahh i had this in unbound: Should have refused to resolve the mozilla check ...
# unbound will not try to resolve any subdomains of that be it the Mozilla or the chrome one.. local-zone: "cloudflare-dns.com" staticBut how IN THE .... would it do any DOH when i have TRR set to 5 ??
-
@bingo600 there is a bunch of doh fqdn that should be block..
As to why it attempted doh while you have trr to 5 that clearly should not happen from my understanding... I set mine to 5, I have the canary setup, and I block a ton of fdqn and IPs for doh.. I am with you - I don't want any of my shit using doh, ever!!
Maybe some addon in FF says don't care what your firefox settings are - I am going to do doh be it you want to or not ;) I sure wouldn't put it past some of these addon makers or even browsers themselves.. Its like they think they are doing you a favor to bypass your local dns.. It is some nonsense that is for sure..
-
@johnpoz said in My FF just had a DOH brainfart:
@bingo600 there is a bunch of doh fqdn that should be block..
That's why i did my "remote list" DOH blocking & hope they'll keep updating.
As to why it attempted doh while you have trr to 5 that clearly should not happen from my understanding... I set mine to 5, I have the canary setup, and I block a ton of fdqn and IPs for doh.. I am with you - I don't want any of my shit using doh, ever!!
Totaly agree
Maybe some addon in FF says don't care what your firefox settings are - I am going to do doh be it you want to or not ;) I sure wouldn't put it past some of these addon makers or even browsers themselves.. Its like they think they are doing you a favor to bypass your local dns.. It is some nonsense that is for sure..
While looking into FF DOH , i saw that there is another way of stopping DOH.
They mention enterprises can set a policy.
That they might honour , else they will be kicked out
The additional checks that will be performed for private āenterpriseā networks are: Is the Firefox security.enterprise_roots.enabled preference set to true? Is any enterprise policy configured? policies.json https://github.com/mozilla/policy-templates#dnsoverhttps -
Hmmm .... I Might owe mozilla/FF an excuse.
$ host github.io github.io has address 185.199.111.153 github.io has address 185.199.110.153 github.io has address 185.199.108.153 github.io has address 185.199.109.153$ host blog.davehylands.com blog.davehylands.com is an alias for dhylands.github.io. dhylands.github.io has address 185.199.108.153 dhylands.github.io has address 185.199.110.153 dhylands.github.io has address 185.199.111.153 dhylands.github.io has address 185.199.109.153 dhylands.github.io has IPv6 address 2606:50c0:8001::153 dhylands.github.io has IPv6 address 2606:50c0:8002::153 dhylands.github.io has IPv6 address 2606:50c0:8003::153 dhylands.github.io has IPv6 address 2606:50c0:8000::153Rethinking that i use an "external list" and that i told it to do https
https://blog.davehylands.com/capturing-usb-serial-using-wireshark/I might think the "List maintainer" has entered all of github.io's wervers to the DOH blocklist , not knowing they also serve HTTPS webpages.
And this is why it's working right now:
$ netstat -pant | grep 185
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 10.xx.xx.xx:45948 185.199.111.153:80 ESTABLISHED 2016/firefoxI have fallen back to http ...
Sorry Mozilla/FF & JP
The servers might do DOH also , but i think i was just doing a https to them
/Bingo
-
@bingo600 yeah that can be problematic if your running services on the same ip as your trying to do doh, people are going to block you that is for sure.
But it does bring to question understanding exactly when FF would check the canary.. So all good in the end..
-
The github ip's seems to have been removed from the list , the pfSense would only have logged those if they were in there.
dhylands.github.io has address 185.199.108.153
dhylands.github.io has address 185.199.110.153
dhylands.github.io has address 185.199.111.153
dhylands.github.io has address 185.199.109.153https://raw.githubusercontent.com/jpgpi250/piholemanual/master/DOHipv4.txt
https://raw.githubusercontent.com/jpgpi250/piholemanual/master/DOHexceptionsIPv4.txtHere i suppose
Mar 23 12:30:55 php-cgi 6601 rc.update_urltables: /etc/rc.update_urltables: Updated UA_DOH_IPV4_JGPI content from https://raw.githubusercontent.com/jpgpi250/piholemanual/master/DOHipv4.txt: 80 addresses added.But as mentioned above .. It got us to dig a bit deeper in FF and DOH (prevention).
And i have learned a lesson in "blindly trust" external lists.
But it's only the 2'nd time in like a year, that i have had issues w. that list.
So it seems OK'ish/Bingo
