4 ms·

No, no no and no. It does not improve privacy, it just puts all your DNS history in the hands of one provider. Not only that it adds latency for no real gain.

No, no no and no. It does not improve privacy, it just puts all your DNS history in the hands of one provider. Not only that it adds latency for no real gain. HTTP is a terrible protocol for anything time sensitive. (its a fairly bad protocol for anything fast or efficient full stop.) The better way to do this is encourage/provide DNSsec (so we know that a provider is who they say they are) and then encrypt dns queries between servers. Firstly that stops everything being centralised by default, (kinda, DNSSec has a chain of trust, so thats centralised) DNS is a massively scalable fault tolerant, distributed key value store. Far faster and more reliable than toys like Etcd and the like. secondly you don't then loose geolocation/provider steering for nearest/fastest node. (yes you can get meta data from IP, but that's not really that useful, that means the _service_ has to figure out how to route your request, not the upstream DNS.) But it needs improvements to make its more anonymous, slapping a fast SSL like tunnel on a resolver combined with DNSsec seems like a much better way to do this and dns over HTTP.

sanxiyn 8y ago
DNS over TLS exists as well. DNS over HTTPS is just another format for DNS over TLS.
- gnode 8y ago
  In my opinion we don't want TLS at all, but rather a UDP based protocol, so that the latency advantages of DNS aren't lost. I believe DNSCurve solves this.
  - sanxiyn 8y ago
    If you want UDP, DNS over DTLS also exists.
    - gnode 8y ago
      Doesn't really save you anything; DTLS still involves a connection with a handshake, so you have increased latency and memory overhead. Its usefulness is in low latency transport where head-of-line blocking would be detrimental (e.g. real-time streaming video; phone calls; VPNs). DNSCurve, by comparison, is connection-less -- meaning no handshake latency, no connection overhead, and denial-of-service resilience.
      - patrickmcmanus 8y ago
        DoH on QUIC is probably the end result
      - bluejekyll 8y ago
        DNSCurve requires an out-of-band process for the exchange of key information. This is how it works around the handshake requirement. It's been a while since I read the spec though, so not sure what the current process is.
  - fanf2 8y ago
    DNS-over-TLS with a persistent connection to the resolver can be more efficient than UDP-based protocols since you can put multiple queries or answers into one packet. DNS supports pipelined queries and out-of-order responses over TCP and TLS so there isn’t a head-of-line blocking problem.
Moru 8y ago
And what happens when I stay at a hotel and need to access the login page of the local lan?
- patrickmcmanus 8y ago
  Firefox has both soft-fail and hard-fail modes.. for a soft fail it will fallback to traditional port 53 DNS. Its likely that will be the most common deployment - you need it to deal with captive portals (i.e. the hotel wifi) and other split horizon issues as well cloud uptime incidents. But there is a hard fail mode if that is suitable for your environment.
  - sanxiyn 8y ago
    Firefox has separate captive portal detection code.
- sanxiyn 8y ago
  Firefox automatically disables DoH if captive portal is detected.
  - patrickmcmanus 8y ago
    not in hard-fail mode; but generally yes.
JTbane 8y ago
I'd agree with you on principle, but Cloudflare has thus far been a very trustworthy company with regards to privacy. The more paranoid (or prudent, depending on your perspective) among us would run their own DNS resolvers.
Lennie 8y ago
I think why Mozilla still doesn't want DNSSEC is because when it breaks it breaks in a big way. And DNSSEC still hasn't got their root key (ksk) rollover process in place. Which is something they would need to properly support to make sure nothing breaks. On the transport front. Eventually I would expect them to use HTTP/2 over UDP/DTLS which is actually pretty darn efficient. It's the IETF standard based on Google QUIC. Which will probably be called QUIC. Because the IETF workgroup is called QUIC.
jiveturkey 8y ago
I can hear the product managers at cloudflare maniacally laughing their heads off right now. A side-effect if you're being generous, or primary motive if you're being cynical, of 1.1.1.1 is that CF acquires all the geo info at the expense of everyone else. This puts CF in a particularly advantageous position over DIY GSLB (pushing content providers into using CF), as well as other CDNs of course. Not only that, the privacy policy promises they will not share resolver data with any other party! lol of course they won't -- why would they give up this competitive advantage! It means they are guaranteeing they will not pass on RFC7871 ECS info. Of course DNS-based geo isn't perfect, and there are other solutions (js pixel timing, anycast, others) but using DNS is still pretty major. Combining it with anycast, as CF does, is surely powerful. Getting FF to use 1.1.1.1 so that "user's don't have to" is incredible. Someone at CF is getting a huge bonus this year.
- r-w 8y ago
  Please do your research. “Any data Cloudflare handles as a result of its resolver for Firefox is as a date processor acting pursuant to Firefox’s data processing instructions. Therefore, the data Cloudflare collects and processes pursuant to its agreement with Firefox is not covered by the Cloudflare Privacy Policy. As part of its agreement with Firefox, Cloudflare has agreed to collect only a limited amount of data about the DNS requests that are sent to the Cloudflare Resolver for Firefox via the Firefox browser. Cloudflare will collect only the following information from Firefox users: […] All of the above information will be stored briefly as part of Cloudflare’s temporary logs, and then permanently deleted within 24 hours of Cloudflare’s receipt of such information.” source: https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/ https://developers.cloudflare.com/1.1.1.1/commitment-to-priv...
  - bluejekyll 8y ago
    > ... DNS requests that are sent to the Cloudflare Resolver for Firefox via the Firefox browser. Is this Firefox specific (via HTTP headers or EDNS options) or is this just the general policy of the 1.1.1.1 resolver for all users?

sanxiyn 8y ago

DNS over TLS exists as well. DNS over HTTPS is just another format for DNS over TLS.

gnode 8y ago
In my opinion we don't want TLS at all, but rather a UDP based protocol, so that the latency advantages of DNS aren't lost. I believe DNSCurve solves this.
- sanxiyn 8y ago
  If you want UDP, DNS over DTLS also exists.
  - gnode 8y ago
    Doesn't really save you anything; DTLS still involves a connection with a handshake, so you have increased latency and memory overhead. Its usefulness is in low latency transport where head-of-line blocking would be detrimental (e.g. real-time streaming video; phone calls; VPNs). DNSCurve, by comparison, is connection-less -- meaning no handshake latency, no connection overhead, and denial-of-service resilience.
    - patrickmcmanus 8y ago
      DoH on QUIC is probably the end result
    - bluejekyll 8y ago
      DNSCurve requires an out-of-band process for the exchange of key information. This is how it works around the handshake requirement. It's been a while since I read the spec though, so not sure what the current process is.
- fanf2 8y ago
  DNS-over-TLS with a persistent connection to the resolver can be more efficient than UDP-based protocols since you can put multiple queries or answers into one packet. DNS supports pipelined queries and out-of-order responses over TCP and TLS so there isn’t a head-of-line blocking problem.

Moru 8y ago

And what happens when I stay at a hotel and need to access the login page of the local lan?

patrickmcmanus 8y ago
Firefox has both soft-fail and hard-fail modes.. for a soft fail it will fallback to traditional port 53 DNS. Its likely that will be the most common deployment - you need it to deal with captive portals (i.e. the hotel wifi) and other split horizon issues as well cloud uptime incidents. But there is a hard fail mode if that is suitable for your environment.
- sanxiyn 8y ago
  Firefox has separate captive portal detection code.
sanxiyn 8y ago
Firefox automatically disables DoH if captive portal is detected.
- patrickmcmanus 8y ago
  not in hard-fail mode; but generally yes.

JTbane 8y ago

I'd agree with you on principle, but Cloudflare has thus far been a very trustworthy company with regards to privacy. The more paranoid (or prudent, depending on your perspective) among us would run their own DNS resolvers.

Lennie 8y ago

I think why Mozilla still doesn't want DNSSEC is because when it breaks it breaks in a big way. And DNSSEC still hasn't got their root key (ksk) rollover process in place. Which is something they would need to properly support to make sure nothing breaks. On the transport front. Eventually I would expect them to use HTTP/2 over UDP/DTLS which is actually pretty darn efficient. It's the IETF standard based on Google QUIC. Which will probably be called QUIC. Because the IETF workgroup is called QUIC.

jiveturkey 8y ago

I can hear the product managers at cloudflare maniacally laughing their heads off right now. A side-effect if you're being generous, or primary motive if you're being cynical, of 1.1.1.1 is that CF acquires all the geo info at the expense of everyone else. This puts CF in a particularly advantageous position over DIY GSLB (pushing content providers into using CF), as well as other CDNs of course. Not only that, the privacy policy promises they will not share resolver data with any other party! lol of course they won't -- why would they give up this competitive advantage! It means they are guaranteeing they will not pass on RFC7871 ECS info. Of course DNS-based geo isn't perfect, and there are other solutions (js pixel timing, anycast, others) but using DNS is still pretty major. Combining it with anycast, as CF does, is surely powerful. Getting FF to use 1.1.1.1 so that "user's don't have to" is incredible. Someone at CF is getting a huge bonus this year.

r-w 8y ago
Please do your research. “Any data Cloudflare handles as a result of its resolver for Firefox is as a date processor acting pursuant to Firefox’s data processing instructions. Therefore, the data Cloudflare collects and processes pursuant to its agreement with Firefox is not covered by the Cloudflare Privacy Policy. As part of its agreement with Firefox, Cloudflare has agreed to collect only a limited amount of data about the DNS requests that are sent to the Cloudflare Resolver for Firefox via the Firefox browser. Cloudflare will collect only the following information from Firefox users: […] All of the above information will be stored briefly as part of Cloudflare’s temporary logs, and then permanently deleted within 24 hours of Cloudflare’s receipt of such information.” source: https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/ https://developers.cloudflare.com/1.1.1.1/commitment-to-priv...
- bluejekyll 8y ago
  > ... DNS requests that are sent to the Cloudflare Resolver for Firefox via the Firefox browser. Is this Firefox specific (via HTTP headers or EDNS options) or is this just the general policy of the 1.1.1.1 resolver for all users?