>> 1) If the traver's laptop/phone uses Heathrow Airport resolvers then Heathro >w > >>4) DNS is not really private so Google may offer their DNS services over HTTP >S >> 5) Governments may force Google to block popular sites, so users switch to >> other DNS resolvers, again over HTTPS. > >See https://developers.google.com/speed/public-dns/docs/dns-over-https >but I don't know how clients bootstrap that API without classic DNS.
The nice this about Google is that they are too big to block. It is not a problem to use plaintext DNS to connect to Google because the CA system and possibly DANE will protect the TLS connection. >block child porn, drug, terrorist, and malware web pages as well as >attempts by corrupted laptops and smart phones to bypass blocks on >port 53 and reach evil or merely unfiltered DNS/HTTPS servers including >those run by Google? I'm not sure what 'HTTPS proxy' means in this context. If a public wifi at an airport can decode TLS traffic then we have a serious security hole. (Of course SNI is a problem. Hopefully TLS 1.3 will improve that) But the bigger problem is that most users don't really care about the difference between a public wifi operated by an airport and a public wifi operated by a criminal. And maybe the criminal just took over the wifi router at a respectable restaurant. So an ISP can null route traffic to known bad destinations (though people may switch to TOR to even deny an ISP even that option) but anything that goes beyond that (ISP access to DNS, etc) also provides great opportunities to attackers. It doesn't really help much if an airport blocks malware but the bar next door doesn't. So for any mobile device, you have to secure the device anyhow. Then this extra protection by ISP mostly becomes another attack vector. So at least for mobile devices it makes sense to make sure that all traffic on the wifi interface is encrypted and we keep the ISP out of the loop as much as possible. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop