Live data from Hacker News

Issues with 1.1.1.1 public resolver and WARP

cloudflarestatus.com

61–70 of 118 posts

Re: Issues with 1.1.1.1 public resolver and WARP

#61
post #45

Earlier quoted context omitted.

As neutrally as possible: Cloudflare doesn't support the DNS Extension that sends part of clients' IPs to the upstream resolver ( https://en.m.wikipedia.org/wiki/EDNS_Client_Subnet ). Cloudflare believes this is better for privacy. Archive.is doesn't like this (because it prevents DNS-based CDN routing), and thus has a hardcoded exception to intentionally return bogus results to Cloudflare's resolvers.

Cloudflare's lack of EDNS doesn't prevent DNS based routing. It can still be done based on the DNS request's source address. This will be the IP of the Cloudflare POP closest to the client. Lack of EDNS only makes DNS based routing slightly worse if your CDN has a POP density similar-or-greater-than Cloudflare's.

Correct. Cloudflare's POP routing is quite extensive, and I'd be shocked if archive.is had more than a handful of backends it's routing to.

Even so, why would an extra few dozen ms matter at all? Archive.is appears to be spindle-limited, is a client with marginally higher RTT an issue? The admin is silly.

https://www.cloudflare.com/network/

Re: Issues with 1.1.1.1 public resolver and WARP

#62
post #60

Earlier quoted context omitted.

I prefer to use my own server as I can optimize cache hit ratios for the things I request. This makes the internet perceptibly faster for me and others on my network. I can also pull statistics from my server whereas I would have to beg someone at the ISP for that data as a one-off request. This also gives me the option to block domain names used for dark patterns or outright malevolent behavior. I also have control…

Interesting, thank you! Yeah, local caching is a good point if your operating system(s) doesn't already do it in the DNS client. > This also gives me the option to block domain names used for dark patterns or outright malevolent behavior. I wonder how long this will actually remain possible, given that with DoH it now seems entirely feasible for websites to provide their own application-level DNS resolver?

Interesting, thank you!

You're quite welcome!

I wonder how long this will actually remain possible, given that with DoH it now seems entirely feasible for websites to provide their own application-level DNS resolver?

For me, forever. Applications can not bypass my DNS unless they are hard coding IP addresses in the application. Windows Update does have some hard coded IP addresses it can fall back on.

It is often said that DoH can't be blocked because in theory it can be hosted on any generic CDN IP pool but to my knowledge this has never been the case. It's quite the opposite, most DoH/DoT providers try to use vanity IP addresses. I null route them and NXDOMAIN the canary domain use-application-dns.net which is entirely optional but a nice gesture to applications to behave. Some vendor may decide one day to host their own DoH/DoT servers but I suspect I would learn about them. I would likely just avoid buying/using that device/application.

Perhaps some day a DoH provider may be so bold as to use a generic CDN pool and I will have to address that issue when it arises. I suspect this would be more challenging for the provider as the app/device will need a way to discover this pool DNS name, HTTP headers, API calls, etc... unless they hard code IP's. Either way I could dynamically null route them.

Re: Issues with 1.1.1.1 public resolver and WARP

#63
post #26

Earlier quoted context omitted.

Switched off 1.1.1.1 for that reason a while back. Currently using OpenDNS which is now unfortunately owned by Cisco. Definitely a lack of actually open alternatives.

I used to use OpenDNS, but then out of nowhere they decided to enable parental control by default[1] and without an account I don’t think I could disable it. [1]: Maybe only in EU?

208.67.222.222 / 208.67.220.220 do not have the functionality worldwide. The IPs ending in .123 do have parental control enabled worldwide

Re: Issues with 1.1.1.1 public resolver and WARP

#64
post #45

Earlier quoted context omitted.

Cloudflare's lack of EDNS doesn't prevent DNS based routing. It can still be done based on the DNS request's source address. This will be the IP of the Cloudflare POP closest to the client. Lack of EDNS only makes DNS based routing slightly worse if your CDN has a POP density similar-or-greater-than Cloudflare's.

Correct. Cloudflare's POP routing is quite extensive, and I'd be shocked if archive.is had more than a handful of backends it's routing to. Even so, why would an extra few dozen ms matter at all? Archive.is appears to be spindle-limited, is a client with marginally higher RTT an issue? The admin is silly. https://www.cloudflare.com/network/

It seems so silly and mysterious that it makes me wonder if archive.today wants exact client IP addresses for some other unstated reason. (It's not clear how/if archive.today, a possibly illegal site, brings in revenue?).

The whole thing is very odd.

Re: Issues with 1.1.1.1 public resolver and WARP

#65
post #60

Earlier quoted context omitted.

Interesting, thank you! Yeah, local caching is a good point if your operating system(s) doesn't already do it in the DNS client. > This also gives me the option to block domain names used for dark patterns or outright malevolent behavior. I wonder how long this will actually remain possible, given that with DoH it now seems entirely feasible for websites to provide their own application-level DNS resolver?

Interesting, thank you! You're quite welcome! I wonder how long this will actually remain possible, given that with DoH it now seems entirely feasible for websites to provide their own application-level DNS resolver? For me, forever. Applications can not bypass my DNS unless they are hard coding IP addresses in the application. Windows Update does have some hard coded IP addresses it can fall back on. It is often sai…

> Applications can not bypass my DNS unless they are hard coding IP addresses in the application.

That's what I mean: What if websites and applications just start querying IP addresses for the hostnames they want to connect to over DoH (to api.someapp.com, so you can't distinguish it from a regular API call that you want to allow for the app to work), and then connect to the resolved IP directly?

Re: Issues with 1.1.1.1 public resolver and WARP

#66
post #48

Earlier quoted context omitted.

> I just talk directly to the root servers from my home network and pre-cache the most popular places I visit. Out of curiosity: Why, if you generally trust your ISP? Do you get worse performance using their DNS servers?

I prefer to use my own server as I can optimize cache hit ratios for the things I request. This makes the internet perceptibly faster for me and others on my network. I can also pull statistics from my server whereas I would have to beg someone at the ISP for that data as a one-off request. This also gives me the option to block domain names used for dark patterns or outright malevolent behavior. I also have control…

But your home DNS server has to talk to some other server to get the IPs right? Usually it's like DNSMasq configured to cache and forward requests to 8.8.8.8 or whatever.

Is there some other option where you talk directly to the top level DNS root and the nameservers directly??

Edit: my bad you said you talk to the root servers directly. Not sure how to delete comments

Re: Issues with 1.1.1.1 public resolver and WARP

#67

Earlier quoted context omitted.

Correct. Cloudflare's POP routing is quite extensive, and I'd be shocked if archive.is had more than a handful of backends it's routing to. Even so, why would an extra few dozen ms matter at all? Archive.is appears to be spindle-limited, is a client with marginally higher RTT an issue? The admin is silly. https://www.cloudflare.com/network/

It seems so silly and mysterious that it makes me wonder if archive.today wants exact client IP addresses for some other unstated reason. (It's not clear how/if archive.today, a possibly illegal site, brings in revenue?). The whole thing is very odd.

There is another reason but it is stated here: https://news.ycombinator.com/item?id=36971650 (routing people to the nearest server _outside_ their own country).

Re: Issues with 1.1.1.1 public resolver and WARP

#68

Note that if you use 1.1.1.1, you apparently can't visit archive.is links. I'm not sure why, but around a dozen people on HN have confirmed this. (At least as of a couple months ago.) I think the world could use more alternatives to 8.8.8.8. Hopefully 1.1.1.1 will become more reliable as the years tick by. (Do you use something besides 8.8.8.8 or 1.1.1.1? If so, post it here! Collecting reliable DNS servers might be…

The reason has been known for a while now. https://news.ycombinator.com/item?id=19828317

and https://news.ycombinator.com/item?id=36971650

Re: Issues with 1.1.1.1 public resolver and WARP

#69

Earlier quoted context omitted.

Correct. Cloudflare's POP routing is quite extensive, and I'd be shocked if archive.is had more than a handful of backends it's routing to. Even so, why would an extra few dozen ms matter at all? Archive.is appears to be spindle-limited, is a client with marginally higher RTT an issue? The admin is silly. https://www.cloudflare.com/network/

It seems so silly and mysterious that it makes me wonder if archive.today wants exact client IP addresses for some other unstated reason. (It's not clear how/if archive.today, a possibly illegal site, brings in revenue?). The whole thing is very odd.

> it makes me wonder if archive.today wants exact client IP addresses for some other unstated reason

They still get the client ip from the request to the service itself (unless you're using a VPN, but if you're using a VPN then archive wouldn't get your ip from your DNS request either).

Re: Issues with 1.1.1.1 public resolver and WARP

#70
post #41
post #14

I’ve just started using Warp+ and it has been excellent for my specific use case: better peering to my Plex server while in another continent. Plex was unusable and now it’s not. Overall very happy despite this brief outage.

I did not know you can use wrap+ like this. I will try it out as well. Plex has been unusable between continents.

You can't use Warp+ to control your egress point, unlike many other VPN services, so you can't use it to bypass geographic blocks. However, since Warp+ (not Warp) routes you within Cloudflare's network (using their Argo routing from participating datacenters), I'd guess GP gets a more stable and faster connection to their server than the public internet would provide.
Post reply on HN