4 ms·

> Otherwise, we are allowing third parties to become the absolute gatekeepers to the sources of authority for finding an IP address. Caches are not authoritativ

> Otherwise, we are allowing third parties to become the absolute gatekeepers to the sources of authority for finding an IP address. Caches are not authoritative sources of DNS data. In theory this is what DNSSEC is meant to provide: cryptographic proof that the cache is giving you unmodified data from the zone's authoritative server(s). Unfortunately... it's still very difficult to run a recursive resolver in a "hardened" configuration that strictly enforces DNSSEC validity, and that's without having a potentially-malicious cache in your query path. The reality is that most networks blocking port 53 are also entirely unaware of DNSSEC, and in such a situation there's really no hope aside from a full-fledged VPN -- or DoH. So I think DoH absolutely does have some use cases, such as clients using broken hotel/conference networks and laptops that are temporarily using insecure public WiFi access points. But it doesn't belong anywhere near my own, properly-configured home and work networks.

3xblah 7y ago
Building DNS resolution into applications, bypassing the OS, is not something I like as a user. It robs me of control. Chrome started down this path and then withdrew. However Golang seems to encourage building applications that do their own DNS resolution. Then there are computers like Chromecasts with hardcoded DNS servers and Apple devices with inaccesible HOSTS files. This sort of design takes control from the user and puts it with the company. Net/Free/OpenBSD still offer a reasonable level of control for those users who want it. The way it was introduced, DOH seems inextricably linked to one application. It is 100% browser-centric. I hope that will change. The internet is more than just a medium for a commercial web. Maybe people will start HTTP tunnelling more than just DNS. As for DNSSEC, it only makes sense to me if one is sharing a cache with others. If it is not a shared cache, if the user has her own caching resolver that connects directly to authoritative servers, then IMO most of the reasoning behind using DNSSEC is gone. What is interesting about some of these DOH comments is that it appears some folks do not want the operator of an authoritative DNS server to know they are sending a query. It seems they want to "hide" behind a third party cache, assuming that is even possible.^1 That sort of "privacy" is not something I care about. I want to cut out the third party DNS middleman. I prefer to query authoritative servers directly without using a recursive resolver (either local or remote), using custom programs I wrote; this is much faster than using a cold cache. The issue for me is control not "privacy". That is the point of the original comment I made about the Mozilla press release. Even NextDNS' FAQ admits a user-managed solution (the example they use is a PiHole) is superior, in terms of "trust", to one managed by a third party, such as NextDNS. 1. I would bet some of the folks complaining about privacy leakage in DOH are using a third party cache that sends EDNS Client Subnet, like Google Public DNS. IMO, if someone is really intent on keeping their DNS lookups private, then the most effective way is to avoid making remote queries. Get the DNS data in bulk and put it in a HOSTS file, a local zone file, "local-data:" in an unbound.conf, etc. There are zone file access programs, public scans and now DOH (outside the browser, via HTTP/1.1 pipelining).

3xblah 7y ago

Building DNS resolution into applications, bypassing the OS, is not something I like as a user. It robs me of control. Chrome started down this path and then withdrew. However Golang seems to encourage building applications that do their own DNS resolution. Then there are computers like Chromecasts with hardcoded DNS servers and Apple devices with inaccesible HOSTS files. This sort of design takes control from the user and puts it with the company. Net/Free/OpenBSD still offer a reasonable level of control for those users who want it. The way it was introduced, DOH seems inextricably linked to one application. It is 100% browser-centric. I hope that will change. The internet is more than just a medium for a commercial web. Maybe people will start HTTP tunnelling more than just DNS. As for DNSSEC, it only makes sense to me if one is sharing a cache with others. If it is not a shared cache, if the user has her own caching resolver that connects directly to authoritative servers, then IMO most of the reasoning behind using DNSSEC is gone. What is interesting about some of these DOH comments is that it appears some folks do not want the operator of an authoritative DNS server to know they are sending a query. It seems they want to "hide" behind a third party cache, assuming that is even possible.^1 That sort of "privacy" is not something I care about. I want to cut out the third party DNS middleman. I prefer to query authoritative servers directly without using a recursive resolver (either local or remote), using custom programs I wrote; this is much faster than using a cold cache. The issue for me is control not "privacy". That is the point of the original comment I made about the Mozilla press release. Even NextDNS' FAQ admits a user-managed solution (the example they use is a PiHole) is superior, in terms of "trust", to one managed by a third party, such as NextDNS. 1. I would bet some of the folks complaining about privacy leakage in DOH are using a third party cache that sends EDNS Client Subnet, like Google Public DNS. IMO, if someone is really intent on keeping their DNS lookups private, then the most effective way is to avoid making remote queries. Get the DNS data in bulk and put it in a HOSTS file, a local zone file, "local-data:" in an unbound.conf, etc. There are zone file access programs, public scans and now DOH (outside the browser, via HTTP/1.1 pipelining).