271–280 of 306 posts
The article lacks instructions about disabling it or using some other DOH resolvers. about:config -> search for network.trr -> set network.trr.mode = 5 to completely disable it (I do not recommend this) The curl wiki has a list of DOH servers: https://github.com/curl/curl/wiki/DNS-over-HTTPS It should also point to "the other side of the story", the benefits of DOH over classic DNS resolving, for example https://hack…
What about if you have private DNS servers that has sites that cloudflare does not have? For example internal intranets etc? So mozilla will not work at all in that case?
The expected common deployment mode is soft fallback - using traditional DNS if connections cannot be made via the DoH resolved address. Captive portal provides the most common use case. There is a hard failure mode available that you can use for better security if you're in a vanilla Internet environment - but we don't see a way to broadly offer that choice other than in technical documentation.
What about if you have private DNS servers that has sites that cloudflare does not have? For example internal intranets etc? So mozilla will not work at all in that case?
It would actually leak the names to the external resolvers.
https://searchfox.org/mozilla-central/rev/3fdc491e118c5cdfba...
Earlier quoted context omitted.
right - but we're coming for cleartext sni too: https://tools.ietf.org/html/draft-rescorla-tls-esni-00 interestingly, something like DoH is a pre-requisite for pulling off esni.
that's great, but are you coming for the ip addresses too (probably the bigger challenge)?
Earlier quoted context omitted.
Which country is that?
VHVya2V5IGhhcyBsZWdhbGlzZWQgY2Vuc29yc2hpcCBvZiBhbGwgcmFkaW8sIFRWIGFuZCBJbnRl cm5ldCBhcyBhbiAiYWRtaW5pc3RyYXRpdmUgbWVhc3VyZSIgaW4gbWlkIDIwMTcgKGxhd2xpa2Ug ZGVjcmVlIDY5MCkuIEFsbCByYWRpbyBhbmQgVFYgdHJhbnNtaXR0ZXJzIChldmVuIG9uZXMgdHJh bnNtaXR0aW5nIHByaXZhdGUgY2hhbm5lbHMpIGFyZSBvd25lZCBieSBhIGdvdmVybm1lbnQtbWFq b3JpdHkgY29tcGFueSBhbmQgYWxsIG5vbi1MQU4gbmV0d29yayB0cmFmZmljIGdvZXMgdGhyb3Vn aCBjZW50cmFsIGdhdGV3YXlzLiBFcmRvxJ9…
openssl s_client -servername news.ycombinator.com -connect news.ycombinator.com:443 /dev/null | openssl x509 -fingerprint -noout -in /dev/stdin
SHA1 Fingerprint=BB:DD:64:6F:EB:11:0C:D5:EC:CF:57:D1:F7:52:AA:99:50:1B:44:FD
Earlier quoted context omitted.
And lets not forget that their CEO will arbitrarily censor and stop serving people he doesn't like. He's done it before. He'll do it again. Cloudflare has already lost my trust.
In his blog post on that, he said pretty clearly that he doesn't want and should not have this power. https://blog.cloudflare.com/why-we-terminated-daily-stormer/ (Disclosure: I work for Cloudflare.)
Earlier quoted context omitted.
> - you can provide your own server Nobody will do this except for maybe 5 individuals and a few dozen cooperations simply because there are no other public DoH servers around.
Many already run their own resolvers, so providing DNS-over-HTTPS proxy is not a problem. What is THE problem, is configuring the browser. No one is going to reconfigure their browser after each connection to a different network. There's a reason why we moved from static configuration towards DHCP, which can configure network-specific settings. DNS is a network-specific setting, and Mozilla is breaking it.
Earlier quoted context omitted.
Can you point to a Mozilla announcement that says they'll turn on DOH by default in a regular non-experimental non-nightly release? This is what Mozilla says in their DOH blog: Our second effort focuses on building a default configuration for DoH servers that puts privacy first. We are running a shield study where some Nightly users will participate in one or more experiments to help us build out a secure, cloud-base…
> Can you point to a Mozilla announcement that says they'll turn on DOH by default in a regular non-experimental non-nightly release? Right on their blog ( https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-ove... ), quoted by the article: "We’d like to turn this on as the default for all of our users. We believe that every one of our users deserves this privacy and security, no matter if they understand DNS le…
Earlier quoted context omitted.
Thanks for answering questions in this thread. This makes a lot more sense - so LAN-only names would still resolve then. This still seems like it could cause problems in certain circumstances, e.g.: - The local DNS server deliberately does not resolve certain hosts (e.g. because it's running PiHole) - An internal host also happens to resolve on the external DNS, though with a different IP. E.g., a company could have…
The most important attribute of DoH is, imo, authentication with the resolver. The browser has a terrible time with 3rd parties messing with the DNS stream. DoH allows the browser to be sure its using the resolver (and therefore the resolver policy) it intends to. > - The local DNS server deliberately does not resolve certain hosts (e.g. because it's running PiHole) The right answer, imo, is that the pihole implement…
This is a worthwhile goal. However, the current UI heavily discourages changing the preset resolver (you have to skip through a warning page, know the correct properties, etc). Do you have any plans for a more acessible UI to set resolvers?
Another point, I think, is that DoH endpoints could be abused by malicious (non-browser) software to hide its communication endpoints.
E.g., when public DoH servers are common and encrypted SNI is operational, a mobile app or IoT device could completely hide with which hosts it is communicating - with no option for the user to override. This doesn't seem to be in the interest of privacy or transparency of data use.
Similarly, a trojan could use a public DoH server as a secure channel to get C&C server addresses, without the name of the C&C server ever getting exposed - or it might even directly obtain commands through it, if the commands can be embedded in DNS records.