2 ms·

Yes, had this problem when I was setting up my pihole and took me a bit to figure out why it wasn't working with firefox. Imagine the sysadmin nightmare if you

Yes, had this problem when I was setting up my pihole and took me a bit to figure out why it wasn't working with firefox. Imagine the sysadmin nightmare if you had to configure 100 different applications on every one of your systems to use the correct server... This is so obviously bad I don't understand.

shawnz 6y ago
I am inclined to think most users use client-side content blocking, and not DNS-based content blocking, which has always been trivially bypassable long before DoH was around. So given that DoH has real and practical security and privacy benefits, and non-DNS based content blocking solutions are already available, are more common, and work more effectively, I don't see how it is such a nightmare to adopt those more secure defaults for everyone. Furthermore I don't think anyone is suggesting "100 different applications" will each have their own resolvers embedded. It makes sense for browsers to be a special case since they are particularly in need of the additional privacy affordances that DoH can provide, and operating system vendors have been slow to implement it.
- CarelessExpert 6y ago
  > I am inclined to think most users use client-side content blocking, and not DNS-based content blocking, I think you're missing the point, here. A lot of enterprises run their own delegating DNS server for a variety of reasons that have nothing to do with ad blocking. DoH breaks that en masse. Firefox has always struggled to gain adoption in corporate settings, and this looks like a nail in the coffin .
  - shawnz 6y ago
    If you control the workstation, you could just set your DNS server by a policy. See: https://github.com/mozilla/policy-templates/blob/master/README.md#dnsoverhttps https://github.com/mozilla/policy-templates/blob/master/READ... Of course that could be easily bypassed, but such a restriction could be easily bypassed by determined employees regardless of whether Firefox natively supports DoH or not. Local intranet sites will still continue to work without any changes because by default it will fall back to the native resolver if DoH can't resolve the domain. So there should be no breakage by default besides for content blocking use cases.

shawnz 6y ago

I am inclined to think most users use client-side content blocking, and not DNS-based content blocking, which has always been trivially bypassable long before DoH was around. So given that DoH has real and practical security and privacy benefits, and non-DNS based content blocking solutions are already available, are more common, and work more effectively, I don't see how it is such a nightmare to adopt those more secure defaults for everyone. Furthermore I don't think anyone is suggesting "100 different applications" will each have their own resolvers embedded. It makes sense for browsers to be a special case since they are particularly in need of the additional privacy affordances that DoH can provide, and operating system vendors have been slow to implement it.

CarelessExpert 6y ago
> I am inclined to think most users use client-side content blocking, and not DNS-based content blocking, I think you're missing the point, here. A lot of enterprises run their own delegating DNS server for a variety of reasons that have nothing to do with ad blocking. DoH breaks that en masse. Firefox has always struggled to gain adoption in corporate settings, and this looks like a nail in the coffin .
- shawnz 6y ago
  If you control the workstation, you could just set your DNS server by a policy. See: https://github.com/mozilla/policy-templates/blob/master/README.md#dnsoverhttps https://github.com/mozilla/policy-templates/blob/master/READ... Of course that could be easily bypassed, but such a restriction could be easily bypassed by determined employees regardless of whether Firefox natively supports DoH or not. Local intranet sites will still continue to work without any changes because by default it will fall back to the native resolver if DoH can't resolve the domain. So there should be no breakage by default besides for content blocking use cases.