Hi! Thanks for all the thoughtful comments about this experiment. The intent of this work is to provide users privacy-respecting DNS. Status quo for DNS does not offer many users reasonable, informed choice about log retention, and doesn't offer encrypted DNS. Users also cannot be reasonably expected to negotiate on their own with their ISPs/VPN providers for things like 24-hour retention for logs that can be used to create profiles. Today's default environment (speaking technically wrt lack of encryption and log storage, and also in terms of the regulatory environment in the US) allows *all* of this data to be collected indefinitely and sold to third parties.
There's a lot of thinking that went into the agreement we have with Cloudflare to enable this experiment in a way that respects user privacy. We also want to explain the impact we think this kind work will have on the privacy of the Internet. I'd like the team to share this in a blog post about the experiment, and so have started work with them on it. More on this shortly! -selena On Mon, Mar 19, 2018 at 8:16 AM Daniel Stenberg <dstenb...@mozilla.com> wrote: > On Mon, 19 Mar 2018, Martin Thomson wrote: > > > I don't know if it is possible to know if you have a manually-configured > DNS > > server, but disabling this experiment there if we can determine that > would > > be good - that might not be something to worry about with Nightly, but it > > seems like it might be needed for this to hit the trains. > > > > How do we otherwise determine that a DNS server is not safe to replace? > > Split horizon DNS is going to cause unexpected failures when users - > > particularly enterprise users - try to reach names that aren't public. > > That's not just an enterprise thing; this will break my home router in > some > > ways as well, though I'm actually totally OK with that in this case :) > > I don't think it is possible - with any particularly high degree of > certainty > - to know if a DNS server has been manually configured (or even if the term > itself is easy to define). The system APIs for name lookups typically don't > even expose which DNS server they use, they just resolve host names to > addresses for us. > > For TRR, we've instead focused pretty hard on providing a > "retry-algorithm" so > that Firefox can (if asked), retry a failed name resolve or TCP connect > without TRR and then "blacklist" that host for further TRR use for a period > into the future. > > For hosts that are TRR-blacklisted this way, we also check the next-level > domain of it in the background to see if we should also blacklist the whole > domain from TRR use. Ie if "www.example.com" fails with TRR, it gets > blacklisted, retried with the native resolver and "example.com" is tested > to > see if the entire domain should be blacklisted. > > -- > > / daniel.haxx.se > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
