Hacker News Reader

Comment by progval | Hacker News Reader

To be fair, there is almost always a corporation able to monitor your DNS resolutions. If not Cloudflare, then your ISP or proxy/VPN provider.

It's a tradeoff based on the relative risks of leaking them to Cloudflare vs ISPs

View on HN

I would a thousand times over rather have my local ISP monitor DNS than Cloudflare. But the choice isn't ISP or Cloudflare. There are many options for secure DNS resolvers [1].

[1] https://dnscrypt.info/public-servers/

Mozilla must have had other criteria:

1. how reliable are these resolvers, right now and in the long term? can Mozilla get an SLA in contract?

2. what is the latency to them? (Cloudflare has PoPs everywhere, so it is likely very hard to beat)

3. what is their privacy policy? can Mozilla get assurances of this?

4. will they be crushed under load if all Firefox browsers on the planet starts using them?

etc.

I am no fan of Cloudflare myself; and avoid it whenever I can. But it is not that bad as a default, for users who don't understand any of these.

// 3. what is their privacy policy? can Mozilla get assurances of this? //

4 providers have contractually agreed to abide by Mozilla’s Trusted Recursive Resolver (TRR) program's policy requirements, so far.

https://wiki.mozilla.org/Security/DOH-resolver-policy#Confor...

CIRA Canadian Shield

Cloudflare

NextDNS

Comcast

I think you need to use the specific DoH URL in the above link to get the contract benefits, but maybe I'm wrong

Cloudflare's DNS violates this: https://wiki.mozilla.org/Security/DOH-resolver-policy#Blocki...

I had a user of my email server complain about not being able to receive emails from "cock.li". Turns out that this happened because I was using dnscrypt-proxy with cloudflare's dns (as it is the default in my distro) and thus the DKIM check was failing because it was not able to resolve the domain as it is being filtered by cloudflare. I changed to NextDNS after that.

I guess it's because the contract is valid only for Mozilla Firefox.

cock.li resolves perfectly fine on Firefox with Cloudflare DoH.

Are you sure? It does not for me. Although I am using my distro's release of Firefox. I will be trying it on my windows pc with the official FF release later.

Sure. Maybe your ISP is blocking the domain or something.

I can access it with my ISP, I can also access it with NextDNS (over DoH) and 8.8.8.8. My friends also reproduced my results from their machines.

Can you run dig @1.1.1.1 cock.li just in case?

That command runs fine. No errors.

Dig does not throw an error when it does not get a result, instead you get an output like this:

    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 49352
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 1232
    ; EDE: 0 (Other): (time limit exceeded)
    ;; QUESTION SECTION:
    ;cock.li.                       IN      A
    
    ;; Query time: 115 msec
    ;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)

In contrast with a successful run like

    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21996
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 512
    ;; QUESTION SECTION:
    ;cock.li.                       IN      A
    
    ;; ANSWER SECTION:
    cock.li.                300     IN      A       193.239.85.202
    
    ;; Query time: 159 msec
    ;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)

Got NOERROR and got the IP of cock.li

So far, only 4 providers have contractually agreed to abide by Mozilla’s Trusted Recursive Resolver (TRR) program's policy requirements.

https://wiki.mozilla.org/Security/DOH-resolver-policy#Confor...

Maybe it's better to choose one among the 4

CIRA Canadian Shield

Cloudflare

NextDNS

Comcast

I think you need to use the specific DoH URL in the above link to get the contract benefits, but maybe I'm wrong

It's not like ISP's aren't shady af when it comes to this. I can appreciate your concern w.r.t. cloudflare but, at least in the US, ISP's are often more ostensibly dangerous than cloudflare.

To suggest that Cloudflare is "thousand times" worse is a bit of a stretch, I guess.

Forgive me if you will, but I don't really understand the idea behind privacy on DNS. If you're not using a VPN, even if the DNS resolution is private, the ISP can still see what IP you're connecting to. It's trivial to do a reverse lookup on that. And if I'm not mistaken, even on HTTPS sites, the domain is visible in the request in plaintext too. So why is there so much focus on proxying DNS?

While encrypted DNS does conceal the domain name from the ISP, it also prevents the ISP from intentionally returning an incorrect IP address in response to a DNS request. This behavior is known as DNS cache poisoning[1] (or DNS spoofing) and has been used by governments to censor websites and perform DDoS attacks on other websites.[2]

[1] https://en.wikipedia.org/wiki/DNS_spoofing

[2] https://www.crowdstrike.com/blog/cyber-kung-fu-great-firewal...

> And if I'm not mistaken, even on HTTPS sites, the domain is visible in the request in plaintext too.

I originally misread this sentence. Yes, HTTPS requests expose the domain/subdomain name in plaintext to support Server Name Indication, which allows a server to host multiple HTTPS sites.[1] The domain/subdomain name can be concealed from the ISP with Encrypted SNI,[2] which Cloudflare's 1.1.1.1 DNS resolver supports.

Firefox used to support ESNI as an about:config option, but in version 85, Firefox replaced it with support for an improved mechanism called Encrypted Client Hello.[3][4] ECH is not widely used yet, though Cloudflare is testing it on some of its servers.[5]

With DNS over HTTPS/TLS and ECH, the entire process of connecting to an HTTPS site can be done without leaking the domain/subdomain name to the ISP. The only remaining parts exposed in plaintext are the remote IP address and port.

[1] https://https.cio.gov/faq/#why-are-domain-names-unencrypted-...

[2] https://www.cloudflare.com/learning/ssl/what-is-encrypted-sn...

[3] https://blog.mozilla.org/security/2021/01/07/encrypted-clien...

[4] https://blog.cloudflare.com/encrypted-client-hello/

[5] https://blog.cloudflare.com/handshake-encryption-endgame-an-...

Thanks a lot for the responses, I understand now :)

>I would a thousand times over rather have my local ISP monitor DNS than Cloudflare.

ISPs lobbied to be able to sell our data. Cloudflare claims that they don't. I trust neither, but I trust Cloudflare %1 more than my scummy ISP.

> But the choice isn't ISP or Cloudflare.

It is when you're talking about the default being offensive to you. The other options haven't been taken away from you.

What’s wrong with cloudflare? Are they worse than Google for some reason?

Some people, perhaps correctly, see them as a centralizing entity for the internet with a profit motive. That they are also currently kind of "eating the world" gives cause for concern. They currently haven't yet betrayed their users but many see it as a matter of time before they begin selling user data.

Happy to be corrected on that last bit by the way if they have done anything egregious.

> if they have done anything egregious.

The way they tried to downplay the significance of Cloudbleed, for starters.

Reply on news.ycombinator.com