Encrypted DNS is a good idea, I just wish all of the basic protocols were getting encryption in-place, instead of being reinvented over HTTPS.
First HTTP/3 (nee QUIC) reinvented TCP and ports over HTTPS, now DOH is reinventing DNS over HTTPS... Sigh. Both of these would be better off by evolving and modernizing their respective existing protocols. And HTTP is a client/server protocol with a _heavy_ handshake cost, why are we using it for a quick one-off request like DNS.
But the problem began decades ago when sysadmins started using firewalls to control what employees could access. During early 2000's I was involved in moving a lot of apps that used a bespoke port to port 80/443 just to make sure our apps and services didn't have any client hiccups due to (rightly so?) belligerent sysadmins.
All this has really done has made sysadmins lives harder bc of packet inspection. So, all app developers and now infrastructure solution devs must run thru 443, otherwise the take up wouldn't happen. The internet is effectively running on one port nowadays.
HTTP had persistent connections ever since HTTP/1.1, and HTTP/2 supports parallel streams within the same persistent connection.
HTTP/3 is still a IETF draft, but is already being deployed pretty much by all big sites. It supports zero-round-trip (0RTT) requests even after the IP of the client has changed.
DoH can essentially match the latency of traditional UDP queries, while also encrypting the channel and traversing any gateways that let HTTPS through.
in my experience, it's not about the protocols, it's about all existing middleboxes blocking/intercepting all traffic on non 443 ports. UDP traffic is notoriously blocked by routers. The only viable option being: HTTPS.
DNSCrypt uses the standard DNS mechanism, and just encrypts the content beforehand. Quick one-off requests. No handshake cost. It uses UDP, or TCP for large responses, exactly like standard DNS. In fact, it can even share port 53 with standard DNS. But can be configured to use TCP/443 if you're on a network where this is the only port that works.
I feel that this everything over HTTPS trend is a scam, I don't know how or why yet, I just feel it.
Perhaps it makes the surveillance tooling more uniform and easier to develop/maintain.
The argument that HTTPS is always available and not filtered is just wrong, anyone who has experience working with large corporations knows that clients use local * certificates and everything is decrypted by the firewall and then re-encrypted. Making HTTPS slow af and sometimes plain broken.
I guess someone will implement a full HTTPS stack in js and announce HTTPS over HTTP to go around this "problem".
My only gripe with DNS over HTTPS is that it seems to somehow be coupled with making it harder for me to actually force everything to use a particular DNS at the OS level, so apps can do things like circumvent your pihole regardless of how you configure your device's DNS settings.
This was very well written. I am pleasantly surprised.
Another concern is that DOH will complicate content delivery to users. Today, content delivery networks
(CDNs) host multiple instances of web content on geographically dispersed servers. This creates
resiliency for web services and helps to deliver content to users more quickly. If ISPs lose the ability to
view users’ DNS queries, they will still be able to route users to a CDN, but not necessarily the closest or
most efficient CDN. Technical measures that may alleviate this concern include sharing some user data
(like general geolocation data) and CDN load management tactics.
Is this a real concern? Don't ISPs just route on IP addresses?
Other potential implications of DOH implementation involve issues such as international data flow and advertising competition.
DNS lookups for CDNs will return a different (local) IP for clients in different regions. The proper way to handle this is using EDNS Client Subnet, which is what Google DOH does. CloudFlare DOH doesn't support this, but instead handles this by making the DNS request from a server near to the end user. This is only roughly accurate, and can't for example point a user's request to their ISP's on-prem edge cache:
https://samknows.com/blog/dns-over-https-performance
That refers to the fact that DoH gives the same old monopolies on the web (Google, Cloudflare) additional web visit signal data, worsening the already appalling state of the economy on the internet captured by Google and Facebook for more than a decade, with naive nerds cheering in the name of technical progress. It also refers to ad blocking no longer being able to block ads based on domain names and IP addresses.
It's referring to the ability of ISPs (as of last year) in the USA being able to use your DNS requests for advertising purposes. The argument for this is to expand competition around ad based products by enabling ISPs to join the game that large web properties currently dominate.
> The Congressional Research Service (CRS), a federal legislative branch agency located within the Library of Congress, serves as shared staff exclusively to congressional committees and Members of Congress. CRS experts assist at every stage of the legislative process — from the early considerations that precede bill drafting, through committee hearings and floor debate, to the oversight of enacted laws and various agency activities.
By its own definition[1], DOH forbids recursive resolution of queries. The client "MUST NOT use a different [DOH resolver] simply because it was discovered outside of the client's configuration"[2].
The protocol seems to be designed to require clients to send all of their DNS traffic to a single upstream provider. This may be similar to your current DNS configuration, and your network may even be limiting your ability to use the internet with bad policies on broken middleboxen. That's unfortunate for you, but please don't presume everyone has similar limitations.
>> "But we need to overload port 443 to hide our DNS traffic!"
It's unfortunate your ISP or national infrastructure requires such obfuscation. In those situations, the current DOH protocol could be a good workaround.
However, protecting against a malicious upstream server sending bad results is very different than protecting against large institutions being able to eavesdrop on your DNS traffic to build a model of your pattern-of-life. The latter is only stopped by not giving a single entity all of your DNS traffic, which DOH explicitly requires.
If you recursively resolve DNS queries locally - ideally in a future where traffic to authoritative servers is encrypted (DoT?) - only the first request goes to a centralized server. Most traffic goes to the domain's authoritative server, which is probably the same controlled by the same entity you are about to connect to with HTTPS.
> Today, DNS queries are generally sent unencrypted. This allows any party between the browser and the resolver to discover which website users want to visit. Such parties can already monitor the IP address with which the browser is communicating, but monitoring DNS queries can identify which specific website users seek. As more services move to cloud computing infrastructure, this distinction becomes increasingly important, because multiple websites may be consolidated under a few IP addresses, rather than each having a unique IP address.
This is super misleading. Even with DoH, any party on the network can see which websites you're talking to, because their hostnames are sent in the clear via SNI. ESNI fixes this, but it's not clear to me whether the major cloud providers are going to go for that, and if they don't it's not going anywhere.
It's only the point-to-point transports that are encrypted, not the queries or responses, that is, the queries and responses are encrypted in transit but would still be cached in the clear for any other queries to benefit from on the resolvers. The caches will work the same as they do today.
Encrypted SNI is on the way. Alternatively, if the site is on a CDN or hosting platform you can usually send any SNI you want and it still resolves to the correct site.
Disclaimer: This will be a wildly unpopular opinion.
I do not believe that DoH was created first and foremost to protect the privacy of people. I believe that it was created to use the frog in boiling water methodology of silently pushing millions of people into centralized logged DNS that can be used for whatever purpose those companies see appropriate, in my personal opinion.
I do not believe this opinion is far fetched. No company is going to just provide a large amount of infrastructure out of the kindness of their hearts. I am not saying that philanthropists do not exist. They do, but not here. This is a data grab first and foremost, in my opinion.
Another factor in my opinion is the lack of support for a corporate infrastructure. Some companies may manage some facets of user settings in Chrome and Firefox via AD policies, but I believe that is the exception rather than the norm. Companies will be leaking even more internal infrastructure topology than they do today. It isn't like ISP's manage browser settings, nor would they want to.
Nation states? DoH will not affect them at all. They will simply null route all of the DoH hosts like they do with existing proxies and VPN providers. This is what I had to do in my home network so that I could maintain control of my DNS.
I think you're arguing against the wrong thing here. You want decentralization of DNS. I don't see DoH really impacting this issue in any clear direction.
On one hand, you have centralized DNS (based on your ISP). DoH gives you some choice over that now through your browser. On the other, you have only a handful of DNS providers to choose from. DoH is just a technology, there's nothing preventing ISPs from still providing their DNS services over HTTPS.
[+] [-] 60654|6 years ago|reply
First HTTP/3 (nee QUIC) reinvented TCP and ports over HTTPS, now DOH is reinventing DNS over HTTPS... Sigh. Both of these would be better off by evolving and modernizing their respective existing protocols. And HTTP is a client/server protocol with a _heavy_ handshake cost, why are we using it for a quick one-off request like DNS.
[+] [-] cmroanirgo|6 years ago|reply
But the problem began decades ago when sysadmins started using firewalls to control what employees could access. During early 2000's I was involved in moving a lot of apps that used a bespoke port to port 80/443 just to make sure our apps and services didn't have any client hiccups due to (rightly so?) belligerent sysadmins.
All this has really done has made sysadmins lives harder bc of packet inspection. So, all app developers and now infrastructure solution devs must run thru 443, otherwise the take up wouldn't happen. The internet is effectively running on one port nowadays.
[+] [-] codewiz|6 years ago|reply
HTTP/3 is still a IETF draft, but is already being deployed pretty much by all big sites. It supports zero-round-trip (0RTT) requests even after the IP of the client has changed.
DoH can essentially match the latency of traditional UDP queries, while also encrypting the channel and traversing any gateways that let HTTPS through.
[+] [-] tveita|6 years ago|reply
This doesn't sound right. QUIC is built on UDP and TLS 1.3, not HTTPS. HTTP/3 doesn't go over itself.
TLS 1.3 also makes the handshake significantly cheaper with the option for 0-RTT resumptions.
DNS isn't really being reinvented either - it's the old wire format with a different framing.
[+] [-] iampims|6 years ago|reply
[+] [-] throw0101a|6 years ago|reply
Well, multi-streaming and multi-homing is part of SCTP, but no one seems to have bothered implementing it.
> now DOH is reinventing DNS over HTTPS... Sigh.
DoT was already invented when the Web folks decided to go and invent DoH:
* https://en.wikipedia.org/wiki/DNS_over_TLS
[+] [-] jedisct1|6 years ago|reply
[+] [-] tamrix|6 years ago|reply
It's on your andriod phone now!
[+] [-] baltbalt|6 years ago|reply
Perhaps it makes the surveillance tooling more uniform and easier to develop/maintain.
The argument that HTTPS is always available and not filtered is just wrong, anyone who has experience working with large corporations knows that clients use local * certificates and everything is decrypted by the firewall and then re-encrypted. Making HTTPS slow af and sometimes plain broken.
I guess someone will implement a full HTTPS stack in js and announce HTTPS over HTTP to go around this "problem".
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] Glyptodon|6 years ago|reply
[+] [-] baroffoos|6 years ago|reply
[+] [-] ma2rten|6 years ago|reply
Another concern is that DOH will complicate content delivery to users. Today, content delivery networks (CDNs) host multiple instances of web content on geographically dispersed servers. This creates resiliency for web services and helps to deliver content to users more quickly. If ISPs lose the ability to view users’ DNS queries, they will still be able to route users to a CDN, but not necessarily the closest or most efficient CDN. Technical measures that may alleviate this concern include sharing some user data (like general geolocation data) and CDN load management tactics.
Is this a real concern? Don't ISPs just route on IP addresses?
Other potential implications of DOH implementation involve issues such as international data flow and advertising competition.
What on earth is this referring to?
[+] [-] ascorbic|6 years ago|reply
[+] [-] tannhaeuser|6 years ago|reply
[+] [-] doctorcroc|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] emddudley|6 years ago|reply
https://crsreports.congress.gov/Home/About
[+] [-] pdkl95|6 years ago|reply
The protocol seems to be designed to require clients to send all of their DNS traffic to a single upstream provider. This may be similar to your current DNS configuration, and your network may even be limiting your ability to use the internet with bad policies on broken middleboxen. That's unfortunate for you, but please don't presume everyone has similar limitations.
>> "But we need to overload port 443 to hide our DNS traffic!"
It's unfortunate your ISP or national infrastructure requires such obfuscation. In those situations, the current DOH protocol could be a good workaround.
However, protecting against a malicious upstream server sending bad results is very different than protecting against large institutions being able to eavesdrop on your DNS traffic to build a model of your pattern-of-life. The latter is only stopped by not giving a single entity all of your DNS traffic, which DOH explicitly requires.
If you recursively resolve DNS queries locally - ideally in a future where traffic to authoritative servers is encrypted (DoT?) - only the first request goes to a centralized server. Most traffic goes to the domain's authoritative server, which is probably the same controlled by the same entity you are about to connect to with HTTPS.
[1] https://news.ycombinator.com/item?id=21110296
[2] https://tools.ietf.org/html/rfc8484#section-3
[+] [-] ameliaquining|6 years ago|reply
This is super misleading. Even with DoH, any party on the network can see which websites you're talking to, because their hostnames are sent in the clear via SNI. ESNI fixes this, but it's not clear to me whether the major cloud providers are going to go for that, and if they don't it's not going anywhere.
https://news.ycombinator.com/item?id=21264814 was a good discussion of the actual security benefits of DoH.
[+] [-] colinprince|6 years ago|reply
0. https://www.bbc.com/news/technology-50073102
[+] [-] ultraism|6 years ago|reply
https://en.wikipedia.org/wiki/List_of_websites_blocked_in_th...
[+] [-] ma2rten|6 years ago|reply
[+] [-] bluejekyll|6 years ago|reply
[+] [-] jedisct1|6 years ago|reply
[+] [-] TheSmiddy|6 years ago|reply
[+] [-] GuyPostington|6 years ago|reply
[+] [-] numlock86|6 years ago|reply
[+] [-] Gaelan|6 years ago|reply
[+] [-] totorovirus|6 years ago|reply
[+] [-] baroffoos|6 years ago|reply
[+] [-] darkhorn|6 years ago|reply
[+] [-] LinuxBender|6 years ago|reply
I do not believe that DoH was created first and foremost to protect the privacy of people. I believe that it was created to use the frog in boiling water methodology of silently pushing millions of people into centralized logged DNS that can be used for whatever purpose those companies see appropriate, in my personal opinion.
I do not believe this opinion is far fetched. No company is going to just provide a large amount of infrastructure out of the kindness of their hearts. I am not saying that philanthropists do not exist. They do, but not here. This is a data grab first and foremost, in my opinion.
Another factor in my opinion is the lack of support for a corporate infrastructure. Some companies may manage some facets of user settings in Chrome and Firefox via AD policies, but I believe that is the exception rather than the norm. Companies will be leaking even more internal infrastructure topology than they do today. It isn't like ISP's manage browser settings, nor would they want to.
Nation states? DoH will not affect them at all. They will simply null route all of the DoH hosts like they do with existing proxies and VPN providers. This is what I had to do in my home network so that I could maintain control of my DNS.
[+] [-] cracker_jacks|6 years ago|reply
On one hand, you have centralized DNS (based on your ISP). DoH gives you some choice over that now through your browser. On the other, you have only a handful of DNS providers to choose from. DoH is just a technology, there's nothing preventing ISPs from still providing their DNS services over HTTPS.