9 ms·
DNS Queries over HTTPS
- tatoalo 8y agoI stumbled upon this when researching wether it was something to set up with my pi as DSN resolver but it was kinda a pita, does implementing DoT would be faster?
- sligor 8y agofor speed the ultimate solution would be DNS over HTTP/3 (DNS-over-HTTP-over-QUIC)
- dochtman 8y agoIn that case, the HTTP part would probably just be working against you. Fortunately, people are working on DNS over QUIC: https://datatracker.ietf.org/doc/draft-huitema-quic-dnsoquic/ https://datatracker.ietf.org/doc/draft-huitema-quic-dnsoquic...
- gsich 8y agoReinvention of the wheel
- sligor 8y agoHTTP only adds a small size overhead due to header formatting but it won't add latency, and DNS requests are in general dominated by connection latency (outside of local network)
- londons_explore 8y agoHTTP adds latency for the first request to a server, since you will have to do the 1-RTT certificate and key exchange before sending your HTTP request. For many use-cases, that penalty will be paid on every request rather than just the first request, because many DNS resolution libraries aren't designed to have persistent state, so every time the library is used, it will have to set up a new connection to the server from scratch.
- jimktrains2 8y agoI think you're confusing http(s) and tls. Http(1) is a request/response protocol. Tls is the stream encryption and key negotiation protocol most heavily used. Also, tls1.3 adds 0rtt for subsequent cqlls to the same server.
- sligor 8y agoyou have also to do this with plain QUIC or with plain TLS adding HTTP on top of both doesn't add RTT, the point was (DNS over QUIC) vs (DNS over HTTP over QUIC)
- Avamander 8y agoAre there any actual implementations being worked on?
- zamadatix 8y agoIf "apt install bind9" (or whatever package manager your distro uses) and editing ~8 lines from 2 text files to make it a secure caching forwarder was too complicated I don't think this would be any easier since it's, at this point, still out of the norm.
- bluejekyll 8y agoAll the major DoH providers appear to also support DoT, so DoT is a viable option. Also it is easier to implement, as it can just be a abstraction of existing implementations over DNS over TCP.
- tatoalo 8y agoI've seen your trust-dns rust-based repo, raspian is supported, I'll give it a try! Thanks
- bluejekyll 8y agoCool, let me know if there's anything there you'd like to see. I'm in the process of working on a system resolver, but first have to refactor a bunch of stuff. We'll see how that goes.
- YouKnowBetter 8y agoThis is the 12th time (see: past) that this subject has been linked. The 3rd time this exact link (ietf.org) has been posted. Except for emotions: do we realy expect a new and exciting discussion will take place?
- proaralyst 8y agoI'm kind of sad that we're using HTTPS as a transport though their use cases make sense. It seems this is intended to exist alongside the existing & new secure protocols? Is it foreseen that this will only be used by web apps?
- dharmab 8y agoYes. No. See also DNS over QUIC.
- groovybits 8y agoSomewhat tangential: HTTP/3, which will also be using QUIC https://tools.ietf.org/html/draft-ietf-quic-http-13 https://tools.ietf.org/html/draft-ietf-quic-http-13
- judge2020 8y agoIsn't HTTP/3 just the name for IETF's QUIC? https://news.ycombinator.com/item?id=18427795 https://news.ycombinator.com/item?id=18427795
- dharmab 8y agoThere's QUIC (protocol) and HTTP/3 (HTTP over QUIC). DNS over QUIC uses the first but not the second.
- groovybits 8y agoQUIC (Quick UDP Internet Connections) is a protocol derived from Google's Speedy project. Another protocol would use QUIC to initiate a handshake between server and client. The cool thing is that it only takes one UDP packet to do what TCP does in the typical SYN/SYN-ACK/ACK.
- jimktrains2 8y agoWell, it's not quite exactly the same thing as the 3-way handshake over a single packet. The 3-way handshake ensures that both ends are able to send traffic to their counterpart. Just because i receive a packet doesn't mean I can send one back.
- detaro 8y agobunch of other large DoH discussions (sometimes about specific implementations, but with generic commentary as well) https://news.ycombinator.com/item?id=16166202 https://news.ycombinator.com/item?id=16166202 https://news.ycombinator.com/item?id=17196415 https://news.ycombinator.com/item?id=17196415 https://news.ycombinator.com/item?id=17222861 https://news.ycombinator.com/item?id=17222861 https://news.ycombinator.com/item?id=17574516 https://news.ycombinator.com/item?id=17574516
- simonpure 8y agoGoogle offers a similar service, but doesn't look to implement any official spec [0]. I recently had a need to resolve DNS with http only and this came in handy. [0] https://developers.google.com/speed/public-dns/docs/dns-over-https https://developers.google.com/speed/public-dns/docs/dns-over...
- deaps 8y agoThis would certainly be huge overhead at the dns server right? I'm curious if anyone manages an authoritative DNS server? I currently manage four rather large ones and the collective whole serves up between 400,000 and 900,000 responses per second.
- londons_explore 8y agoPossibly load would in fact go down. Current DNS requests over UDP can (and frequently are) spoofed because there is no way of validating the sender is who they say they are. With DNSoverHTTPS, the sender must be able to receive replies at their IP address, so cannot spoof who they are easily, closing off a lot of avenues for DoS attecks on your and other peoples recursive resolvers.
- jedisct1 8y agoHTTPS is not required to mitigate this. Spoofing the sender IP is only useful to conduct DNS reflection attacks, where a small question is sent, and a much larger response is sent back to the (possibly spoofed source IP). If you require the question to be at least as large as the response, amplification is not a concern any more, so UDP is perfectly fine. This is what the DNSCrypt protocol is doing.
- londons_explore 8y ago1 Million responses per second on a 8 core 2 Ghz mahine means you have 16,000 clock cycles to formulate a response to each query. Considering that [1] claims 1.43 cycles per byte for Chacha20, and assuming requests & responses are typically 200 bytes (they will compress well with HTTP header compression), the actual encryption part of https only consumes 1.43 * 200 = 286 cycles. The remaining 15,716 clock cycles should be plenty to read the actual responses from the cache and parse the HTTP/2 request bytes. Obviously all of the above assumes you design your infrastructure purely for performance. Writing everything in Python and NodeJS might suddenly burn up all those 15,716 clock cycles! [1]: https://eprint.iacr.org/2013/759.pdf https://eprint.iacr.org/2013/759.pdf
- 8y ago
- sytse 8y ago'[RFC2818] defines how HTTPS verifies the DoH server's identity.' that RFC is TLS over HTTP How do you resolve the IP address of your DoH server? Is the answer to just use an IP address? In that case does it have a certificate for the IP addresses instead of for a FQDN?
- Aissen 8y agoYou use a name by default, and if you want to bypass resolution with a system DNS, you hardcode it's IP alongside the name. For example, in firefox: network.trr.bootstrapAddress - (default: none) by setting this field to the IP address of the host name used in "network.trr.uri", you can bypass using the system native resolver for it. This avoids that initial (native) name resolve for the host name mentioned in the network.trr.uri pref. https://daniel.haxx.se/blog/2018/06/03/inside-firefoxs-doh-engine/ https://daniel.haxx.se/blog/2018/06/03/inside-firefoxs-doh-e...
- callahad 8y ago> In that case does it have a certificate for the IP addresses instead of for a FQDN? It can be both: If you look at https://1.1.1.1/ https://1.1.1.1/, the certificate is issued for *.cloudflare-dns.com, but it also contains the alternative names 1.1.1.1 and 1.0.0.1.
- jedisct1 8y agoThe bootstrap IPs, or the IPs themselves, can be part of the DNS stamp: https://dnscrypt.info/stamps-specifications https://dnscrypt.info/stamps-specifications The name used to check the certificate and the URL are also distinct. For example, look at the stamp for Cloudflare: https://github.com/DNSCrypt/dnscrypt-resolvers/blob/master/v2/public-resolvers.md#cloudflare https://github.com/DNSCrypt/dnscrypt-resolvers/blob/master/v... It defines https://1.0.0.1/dns-query https://1.0.0.1/dns-query for the URL, but dns.cloudflare.com for the certificate name.
- LinuxBender 8y agoPlease forgive me if this has been covered. AFAIK it has not. Has anyone worked out how this will play nicely in corporate environments? i.e. avoiding leaking even more internal names, resolving internal systems first, etc? Or is it on IT departments to now customize the proxy settings for all browsers and API clients on all operating systems? I ask, because I know that most companies barely manage this on one browser, much less all of them. I am not in IT, but I am occasionally required to assist them and sometimes that requires capturing DNS requests for entire networks.
- yjftsjthsd-h 8y agoCorrect me if I'm wrong, but I'm pretty sure that this is in fact designed to break that kind of arrangement. The problem is that the mechanics used for corporate monitoring are almost exactly the same mechanics used for your ISP spy on you or censor things. So yes, the end result is that we will need to move monitoring (and potentially blocking if you're doing that) onto the endpoints.
- lwheelock 8y agoNot necessarily, it depends on the egress architecture. There are ways to do corporate monitoring that cannot be done by your ISP. Web content filters (aka Proxies) in a transparent mode deployment that are not performing TLS interception would not be able to monitor these queries if wrapped in TLS. However, an explicit mode deployment and all 80/443 traffic enforced by an egress firewall through the proxy that was performing TLS interception can still monitor this traffic. In fact, even if you’re not brokering TLS, the GET method described can still leak the query (but not response) unless your client uses tunneling (ie. CONNECT method). ISPs can’t force you to use an explicit proxy, but corporations can.
- LinuxBender 8y agoThat is a challenge for us as well. Many of our partners use MitM proxies, but our privacy, compliance and legal teams will not approve the usage of them. We promote a work-life balance which means we allow people to use work resources for personal use. Culturally, that is great. It does create this conundrum however. The company does not want to be liable for intercepting personal and financial data that does not belong to us.
- slim 8y agoIt's 2019 and we have DNS over TCP and HTTP over UDP
- drudru11 8y agoLol - best HN reply I’ve read in a while
- wahern 8y agoDNS has always been available over TCP. The DNS packet header has a Truncated (TC) bit that tells you when you should query over TCP, as UDP responses are usually truncated at ~500 bytes. DNS over TCP can often provide better throughput and lower latency, especially on networks with a lot of packet loss (which can be your network if you're, say, batch resolving IP address PTR records from a log where your DNS UDP requests overflow the kernel and NIC TX buffers).
- AnaniasAnanas 8y agoDNS Queries over HTTPS.. which implies TCP. Weren't TCP DNS requests avoided like the plague? And why wrap DNS in HTTPS instead of just TLS if you are going down the TCP route? Why not DNSCrypt which is already supported by a lot of servers? Or DNSCurve.. or DNS over QUIC.
- Spivak 8y agoYou do both. Both Google and Cloudflare run DNSoTLS on port 853 and DNSoHTTPS on port 443. DNSoTLS and DNSoHTTPS in their short lives have already gained more traction than DNSCrypt ever got. DNSoQUIC is already in the pipeline.
- jedisct1 8y ago> DNSoTLS and DNSoHTTPS in their short lives have already gained more traction than DNSCrypt ever got I'm not convinced at all that this is true. Cisco, Comodo, Infoblox, Yandex, support DNSCrypt only in their products. They have no reason to switch to protocols that would require 10x more traffic. OpenNIC secure resolvers are all DNSCrypt. Cleanbrowsing resolvers probably get a lot of connections over DNSCrypt as well. I run both public resolvers accessible over DoH and DNSCrypt, and the traffic over DoH is negligible compared to the DNSCrypt one.