Live data from Hacker News

1.1.1.1 for Families

blog.cloudflare.com

131–140 of 171 posts

Re: 1.1.1.1 for Families

#131
post #100

Earlier quoted context omitted.

> I don't particularly care what the details are, whose fault it is, etc. https://jarv.is/notes/cloudflare-dns-archive-is-blocked/

From the article above: > In other words, Archive.is's nameservers throw a hissy fit and return a bogus IP when Cloudflare doesn't leak your geolocation info to them via the optional EDNS client subnet feature. The owner of Archive.is has plainly admitted this with a questionable claim (in my opinion) about the lack of EDNS information causing him "so many troubles." Not sure how it’s causing him so many troubles.

> Not sure how it’s causing him so many troubles.

The allegation is that Cloudflare's in the (anycast) CDN business, hence its customers do not require EDNS (ECS) to be steered to the geographically-nearest server, and so, they naturally want to kill EDNS (ECS) and that privacy's just an excuse.

As a consumer, I agree with what Cloudflare's doing (though they could potentially engineer a solution to send fake/blind EDNS (ECS)). Wearing my developer hat, I also agree with archive.is' decision to stage a protest.

Re: 1.1.1.1 for Families

#132
post #55

I was happy to set up 1.1.1.1 for my daughter on her Iphone7 but it never seemed to work well with Mobile Data (Freedom Mobile Canada). Internet would always be spotty/non-existent. The app being used was Google Classroom. In the end we turned off 1.1.1.1 and Google Classroom started working. Anyone experience anything similar?

Did you set up both 1.1.1.3/1.0.0.3 and also 2606:4700:4700::1113/2606:4700:4700::1003? Maybe there was some IPv6 issues. https://developers.cloudflare.com/1.1.1.1/1.1.1.1-for-famili...

this is definitely the solution, mobile is mostly ipv6 in my experience

Re: 1.1.1.1 for Families

#134
post #110
post #92

Earlier quoted context omitted.

This has come up a few times. Mostly the owner is set in their ways and are mad at CF for not providing the DNS flags that allow outside CDNs to figure out what IP you are closest to. From a 2019 thread about this: The archive.is owner has explained that he returns bad results to us because we don’t pass along the EDNS subnet information. This information leaks information about a requester’s IP and, in turn, sacrifi…

Can you explain the attack a bit more? One would (naively) expect that the process of the user connecting to my web server would expose their IP address (associated with their intent) to many more relevant actors (including "nationstate actors") than Cloudflare connecting to my DNS server... is the issue that the specific nationstate actor you have been concerned with is explicitly able to target and achieve surveill…

The "attack" is bad implementations revealing the whole IP, leaking that PII, to anybody watching DNS, instead of the query being masked to a /20, or some other subnet.

Not all VPNs route DNS queries over the VPN for performance reasons. Thus, knowing that a specific IP is visiting dissident net when that cannot be directly observed is very useful.

Re: 1.1.1.1 for Families

#135

Well one of my domains resolves to some dodgy russian website when using cloudflare's dns. I did everything in my power, including trying to contact them, but it still resolves to the russian host. On any other dns server it resolves correctly to gandi's parking page. Cloudflare did send me an email within 10 seconds to say that no support ticket can/will be logged since I'm not a paying customer (or just customer on…

And the reason why it pissed me off was, I thought my mikrotik router or raspberry pi + pihole got compromised. I spent two hours trying to track down the problem, reset all dns setting on gandi, resetting and updating the router etc... just to find that it worked fine on my phone on MNO's network...then I digged further and found if I switch my dns to anything other than 1.1.1.1, it worked fine. So I don't care what…

That seems less "sticking to principles" and more "we aren't resolving correctly, but can't/won't tell you why?"

Re: 1.1.1.1 for Families

#137

Who bears the brunt of the task of collecting every adult/NSFW domain out there? Doesn't such a list grow by huge numbers each day? What is the name of this list, and where can I get it?

Search for block lists, here’s a popular one that is updated regularly. https://raw.githubusercontent.com/StevenBlack/hosts/master/a...

Wow. Incredible list. Thanks for sharing.

Noticed some of them weren't NSFW domains, just problematic ad-tech domains, but still very useful.

Re: 1.1.1.1 for Families

#138

Well one of my domains resolves to some dodgy russian website when using cloudflare's dns. I did everything in my power, including trying to contact them, but it still resolves to the russian host. On any other dns server it resolves correctly to gandi's parking page. Cloudflare did send me an email within 10 seconds to say that no support ticket can/will be logged since I'm not a paying customer (or just customer on…

That's an odd problem. A few possible causes jump to mind:

A. Someone is poisoning it between you and Cloudflare, but only for DNS requests directed towards Cloudflare.

B. Someone is poisoning it between Cloudflare and Gandi.

C. Someone was able to trick Cloudflare into thinking it is the authoritative DNS provider and its authoritative DNS servers are the same ones as its recursive resolvers.

D. Something got missed in troubleshooting. (Not trying to be a jerk, it's just always a possibility.)

You could probably surface whether it's A or B by playing around with DNSSEC.

I'm not certain, but you might be able to figure out if it's C with this: https://rdap.cloudflare.com

Re: 1.1.1.1 for Families

#139
post #129

Earlier quoted context omitted.

>It would be nice if all servers supported DoT/DoH + DNSSEC and you could roll your own recursive DNS server and have more trust in traffic not being intercepted. I love DNSSEC, but am not in favor of DoH/DoT. Mostly because I can't control DoH/DoT requests emanating from my network, as they're already encrypted and can't be differentiated from standard HTTPS traffic. That's an issue (and will become a much bigger on…

I don't think my ISP can easily intercept the content of DoT DNS requests. They would need a valid certificate for 1.1.1.1#cloudflare-dns.com or 9.9.9.9#dns.quad9.net from a trusted (by me) CA, correct? Now obviously that's not impossible but is a VPN any better in that scenario?

>I don't think my ISP can easily intercept the content of DoT DNS requests.

No. But they can intercept connections to the IP addresses returned by such DNS queries.

>They would need a valid certificate for 1.1.1.1#cloudflare-dns.com or 9.9.9.9#dns.quad9.net from a trusted (by me) CA, correct?

In order to MiTM such requests, yes.

>Now obviously that's not impossible but is a VPN any better in that scenario?

You're only considering the DNS queries. Once you've received a response to your DoT/DoH query, presumably you'll want to connect to the returned IP address, right?

Your ISP can absolutely capture those packets, and even if the payload is encrypted, the headers are not -- so while they might not be able to access the data, they have full access to the metadata. Unless you use a VPN, which will encapsulate the headers as well.

All that said, my issue is with DoH/DoT, since devices can stealthily bypass my DNS controls (including ad/telemetry blockers like Pi-Hole) and unless I block all TLS/HTTPS traffic (making my internet link mostly useless), I can't stop surreptitious connectivity.

I'm not as concerned with my ISP as I am with not being able to block ads/tracking/telemetry. Apologies if I wasn't clear about that.

Re: 1.1.1.1 for Families

#140

Earlier quoted context omitted.

> I used to use 1.1.1.1 till the day I realized that it doesn't resolve archive.is. It does resolve archive.is, it’s just the archive.is nameservers return garbage if the source if CloudFlare. CloudFlare could simply fix this their end if they wanted but haven’t done so out of integrity. This looks good for CloudFlare and bad for archive.is from where I’m sitting.

Is there any non-conspiratorial reason for archive.is's position on this?

Yes. From a technical standpoint, archive.is' stance is that it's actually important useful data that, more importantly, isn't a privacy violation. How much you agree with archive.is depends on a very technical understanding of the subject, or barring that, it depends on how much you buy Cloudflare's reasoning. Cloudflare's business would prefer you pay for Cloudflare (at large but specifically their anycast) instead of using an optimization available to you as a Internet business to route clients to a more optimal/closer server.

As far as the privacy implications, remember that the site you visit needs to know your IP address in order to respond to your request, so while there are some issues to be aware of, it's kind of hard to see it as a privacy violation and not Cloudflare trying to squash the little guy, imo.

Post reply on HN