Live data from Hacker News

Issues with 1.1.1.1 public resolver and WARP

cloudflarestatus.com

71–80 of 118 posts

Re: Issues with 1.1.1.1 public resolver and WARP

#71
post #65

Earlier quoted context omitted.

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?

The heavy-handed solution looks like this:

    local-zone: "api.someapp.com." always_nxdomain
Then I reach out to them and say something to the effect of, "Hey, nice application/device you have there! In order for anyone on my network to utilize this app/device the DNS would need to be put back into your DNS servers and removed from the API records." Of course they will laugh at me but that is fine given that 100% of the internet and internet connected devices are entirely optional for me. It is unlikely that a statistically significant number of people would use this heavy handed approach. Or perhaps I am OK with their API method and make use of their API that bypasses DNS. This probably depends on if this is malicious or not. i.e. serving ads or malware

Another heavy-handed option would be to force all traffic through a MITM proxy which I have done in the past. Any device that can't have my CA cert loaded would be a paperweight and thus returned to Amazon with less than 5 stars and a review that details the DNS implementation which most customers would not care about or understand but my fellow cranky network admins may find useful. If it's a website then I would just not use it. Some businesses take this approach. There are both commercial and open source solutions for this. Look for Squid SSL-Bump MITM proxy if one is curious. This requires bypasses for domains still using public key pinning which is an insignificant number of them. Most have moved away from HPKP due to the induced fragility and risks.

There are other methods but they come with security implications such as decompiling applications, shimming something into it or pre-loading libraries to do the same thing but this usually requires rooting a device and potentially compromising security as the vendor signing may be removed. I'm sure some of the mobile developers here have more elegant and secure methods.

I doubt many would do any of this of course, but you asked.

Re: Issues with 1.1.1.1 public resolver and WARP

#72
post #66

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…

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

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

It's still a valid question. You are right, one has to bootstrap the root servers. There are a few ways to do this. Assuming one had working DNS server at some point in the past they can

    dig @e.root-servers.net +nocookie +tries=4 +retry=4 +time=8 . ns | grep -Ev "^;|^$" > /etc/unbound/named_hints.tmp # sanity check this
and then do sanity checks on the output prior to loading it as hints in Unbound DNS. The 3K or so root servers are Anycast IP addresses and rarely change so this file will not be stagnant for a very long time thus making thumb drives a valid way to store and transfer this file.

Re: Issues with 1.1.1.1 public resolver and WARP

#73

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…

You can use quad9 without filters, and i use it because unlike CF it supports EDNS(9.9.9.11)

Duuuuuude, thank you so much! I was using 9.9.9.9 and it didn't work for me at all. Got stuck in a loop with the captcha for months now. Archive.is is essential for me. Using 9.9.9.11 fixed it for me.

Re: Issues with 1.1.1.1 public resolver and WARP

#74

What's the point of having a secondary endpoint 1.0.0.1 if an outage breaks both that and 1.1.1.1? Are these two servers not running in physically isolated regions with independent code deploys?

Will DNS clients actually try the other if one of them returns SERVFAIL?

Re: Issues with 1.1.1.1 public resolver and WARP

#76

What's the point of having a secondary endpoint 1.0.0.1 if an outage breaks both that and 1.1.1.1? Are these two servers not running in physically isolated regions with independent code deploys?

Will DNS clients actually try the other if one of them returns SERVFAIL?

Yes.

Re: Issues with 1.1.1.1 public resolver and WARP

#77

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…

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.

If I understand this correctly, that's hilarious -- Cloudflare is essentially saying that nobody can layer their own cloudflare-like offering on top of their DNS. Edge-routing is their bread and butter!

If you want to use the client's IP geolocation to resolve a CNAME to an edge server, this blocks you from doing so. You have to buy Cloudflare's products to get this benefit, and use their edge servers.

Re: Issues with 1.1.1.1 public resolver and WARP

#78

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…

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.

There are two missing facts here that change the story quite a bit:

- In addition to not supporting EDNS, Cloudflare sends DNS requests from effectively random PoPs, so the recipient doesn’t know even the visitor’s nationality.

- The reason archive.is doesn’t like this is it makes them vulnerable to DoS attack.

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

Re: Issues with 1.1.1.1 public resolver and WARP

#79

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.

If I understand this correctly, that's hilarious -- Cloudflare is essentially saying that nobody can layer their own cloudflare-like offering on top of their DNS. Edge-routing is their bread and butter! If you want to use the client's IP geolocation to resolve a CNAME to an edge server, this blocks you from doing so. You have to buy Cloudflare's products to get this benefit, and use their edge servers.

No, they don't, please read this before making unresearched guesses ( note: I had the same reaction at first a couple of years ago).

They forward every info that is required for cdn's to function, that's why no other cdn's are complaining.

See the statement of the CEO:

https://news.ycombinator.com/item?id=19828317

Tldr:

> We publish the geolocation information of the IPs that we query from. That allows any network with less density than we have to properly return DNS-targeted results. For a relatively small operator like archive.is, there would be no loss in geo load balancing fidelity relying on the location of the Cloudflare PoP in lieu of EDNS IP subnets.

We are working with the small number of networks with a higher network/ISP density than Cloudflare (e.g., Netflix, Facebook, Google/YouTube) to come up with an EDNS IP Subnet alternative that gets them the information they need for geolocation targeting without risking user privacy and security.

Re: Issues with 1.1.1.1 public resolver and WARP

#80
post #18

Earlier quoted context omitted.

There is https://www.dns0.eu and https://nextdns.io . I like the 300K requests per month free tier that nextdns.io has. Comes with plenty of filters.

I’m a big fan of NextDNS, ad filters, logs (or not), block list, allow list, multiple profiles, parental-ish controls. They have binaries to add support for DoH to my router. I literally couldn’t be happier with a DNS provider.

My one gripe is with the block / parental controls interface.

Let’s say you want to block Peacock, and there’s a bunch of urls you want to block, each is it’s own individual rule. If you accidentally delete one instead of disable it, it’s gone. If you can remember the url you accidentally deleted, now it’s placed at the top of the list, out of order. There appears to be no log of changes you make. It would be nice to be able to add custom parental controls with sets/bundles of urls.

Also you can’t toggle or package ad blocking rules, only delete and add. Sort of the same interface complaint as above. I have to go in and delete four ad blocking packages every time I want to watch Paramount+. Then go find them again when I am done.

Post reply on HN