SoylentNews is people
SoylentNews
https://www.theregister.co.uk/2019/09/10/chrome_78_dnsoverhttps/
Only days after Mozilla said it plans to make DNS-over-HTTPS (DoH) available by default gradually for Firefox users in the US, Google announced its intention to test DoH in Chrome 78, due for beta release in the next two weeks.
DoH wraps domain-name queries in a secure, encrypted HTTPS connection to a DNS server, rather than firing off requests using bog-standard plain-text insecure DNS, thereby keeping queries inaccessible to eavesdroppers. It's one of several emerging internet protocols intended to close security and privacy gaps in online communications.
Google's experiment will involve checking whether Chrome 78 users' DNS provider is among six services selected for their readiness to test DoH – Cleanbrowsing, Cloudflare, DNS.SB, Google, OpenDNS and Quad9. And if so, Chrome will switch from standard DNS to DoH using the same service provider, at least for those lucky few in the experimental group.
Google is thus avoiding one of the concerns raised by Mozilla's approach, forcing Firefox users to change their chosen DNS provider for Cloudflare. In so doing, Google ensures that malware screening and parental filtering capabilities offered by DNS providers will continue to function, if possible under DoH.
(Score: 3, Interesting) by Anonymous Coward on Friday September 13 2019, @11:08AM (5 children)
So, as my ISP has a Netflix box to serve up content directly, if I use Firefox's DNS-over-HTTPS (which uses CloudFlare's 1.1.1.1), Netflix's DNS servers won't see the query coming from my ISP's default recursive DNS servers, and so won't hand out those local direct content server box IPs, potentially exposing my Netflix streams to remote network bottlenecks. Same for Chrome and Google's DNS-over-HTTPS. And I hand over my "privacy" to Google or CloudFlare (who has issued a new separate DoH policy statement). My ISP won't know my queries any more. That may or may not be a plus. But for me, I trust my local ISP more than Google or CloudFlare.
I'm such a geek that I run my own recursive DNS server on my house network, one that does full DNSSEC checking. So really I won't be using DoH as it buys me ZERO privacy improvement and ZERO security improvement. And because my own resolver originates requests from IP blocks announced via BGP by my local ISP, I won't really encounter any Netflix or other content delivery network local-cache/server issues thst other DoH users will.
Too bad route manufacturers aren't shipping options for users to run a DNSSEC-validating recursive resolver on the router (so long as the router's firmware is well-maintained for security fixes). Except for cases of guests not trusting the local LAN or WiFi network, that gives home or small businesses a sweet alternative. ESPECIALLY if that local resolver can ALSO do DoH. (I plan on enabling DoH on my home DNSSEC-validating recursive server soon.)
(Score: 0) by Anonymous Coward on Friday September 13 2019, @11:10AM (3 children)
Didn't you see that Google's DoH test won't change your DNS if you're using your local ISP's servers--unless your ISP is one of those listed DoH providers in which case DoH DNS won't change anything for you except encrypting your requests over the wire to your provider?
(Score: 5, Interesting) by Anonymous Coward on Friday September 13 2019, @12:07PM (2 children)
You believe this?
currently I transparently redirect all DNS queries on my home network to my own server, so for example, if a browser/phone/whatever tries to look up www.googleadservices.com
| bash-4.3$ nslookup
| >server 8.8.8.8
| Default Server: 8.8.8.8
| Address: 8.8.8.8#53
| >www.googleadservices.com
| Server: 8.8.8.8
| Address: 8.8.8.8#53
|
| Name: www.googleadservices.com
| Address: 127.0.0.9
On the server
| bash-4.3$ nslookup www.googleadservices.com
| Server: 127.0.0.1
| Address: 127.0.0.1#53
|
| Name: www.googleadservices.com
| Address: 127.0.0.9
I've had to go this route as I've spotted google's code trying their own servers rather than the system configured ones, the apparent usual steps being
1. Code tries to resolve a.google.domain using system configured DNS server
2. If code gets no response, or doesn't like/trust the result, it then tries to resolve a.google.domain using a Google DNS server.
to which we'll now have to add
3. If the code doesn't like the result of resolve a.google.domain using 'standard' DNS, it'll then try DoH....fuck it, it'll just use DoH for all Google related name resolution out of the box...
Even when I set up my own DoH server (as I'm doing in preparation to mitigate the Firefox DoH fuckwittery) , I've no doubt that Google will either fucking ignore it or make it as difficult as possible to bypass it for resolution of *their* domain names..I can see I'm going to have to do a lot more reading, 'playing' and planning here than I expected.
(Score: 2) by corey on Friday September 13 2019, @09:54PM
Is this from Android or Chrome, or chrome on Android? Love to know more details.
How are you redirecting DNS queries? A la transparent squid.
I have set up DNSSEC and DNS over TLS on my unbound server, works well except higher latency as I'm not using my ISP DNS server.
On another note, I just installed Blokada on my android phone, it's been picking up heaps of connections to the likes of mtalk.google.com, alt1-mtalk.google.com, play.googleapis.com, android.clients.google.com and heaps more. Over and over every minute or less.
(Score: 0) by Anonymous Coward on Saturday September 14 2019, @01:22AM
Just add the stuff to your firewall. Block port 53 on both UDP and TCP from leaving your network, except from you server and it is solved. For DoH, just block all traffic to Google's DNS servers, as they almost have to use hard-coded IP addresses to bootstrap the process. Heck, you can even check your firewall for addresses not previously resolved via your DNS server, or set it up to not allow any connection out that isn't on your whitelist or resolved greylist.
(Score: 0) by Anonymous Coward on Friday September 13 2019, @02:41PM
it is bad bad form for ANY content distribution network to rely on the user-queried DNServer to provide location.
sure, for the content provider it saves computing time but they should really check the geo location of the content requesting IP themselfs.
whatever dnserver is configured by user should have NO influence whatsoever on which content-distribution server is assigned.
the user IP (requesting) MUST be enough to get the nearest (and correct) content mirror assigned.
idiots.