3 ms·

If the user is sitting behind a filtered port 53, e.g., at a hotel, running her own resolver will not solve the problem. This filtering of port 53 may be growin

by 3xblah 7y ago

If the user is sitting behind a filtered port 53, e.g., at a hotel, running her own resolver will not solve the problem. This filtering of port 53 may be growing in popularity among ISPs. If it is, then that means users cannot easily choose their own source of DNS data. It becomes necessary to connect to some remote computer you control that can send traffic on port 53 just to send an authoritative DNS query. It is like having to pay two ISPs now instead of one. What are the "free" workarounds. There are free-trial DNS "relocator" services and DNSCrypt resolvers running on ports other than 53 (I am not aware of any authoritative servers running behind dnscrypt-wrapper). Now there are also "DOH servers" running on port 443, serving resolver responses via HTTP. One unique feature of DOH -- for those doing bulk lookups -- is that one can query multiple names with a single packet. That is not possible using the DNS protocol. For folks who are stuck with port 53 filtering, as a temporary solution, I would like to see more remote DNS servers, both recursive and authoritative, running on ports other than 53. They do not have to be "relocator" services, encrypted or served via HTTP. They just need to use ports other than 53. Then, when running a local resolver, the user can set it to forward queries to a remote one listening on a non-standard port or she can query authoritative servers directly, e.g., root or .com servers, using stub resolvers. It is every internet user's right to be able to query the authoritative servers for a domain's IP address -- whether from her own local resolver or from a stub, the same way it is to request access to a public zone file. Filtering port 53 is unacceptable. 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.

kiwidrew 7y ago
> 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).

by 3xblah 7y ago

kiwidrew 7y ago

> 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).