Live data from Hacker News

Issues with 1.1.1.1 public resolver and WARP

cloudflarestatus.com

101–110 of 118 posts

Re: Issues with 1.1.1.1 public resolver and WARP

#101
post #23

Just a reminder for anyone on the fence, or who has not considered it previously... Running your own DNS resolver is super easy. It probably has the highest ROI of any self-hosted service, because it is so easy and inexpensive to do. I recommend Unbound: https://nlnetlabs.nl/projects/unbound

How slow is running your own recursive DNS?

I run my own resolver on my home network and I never notice anything. When loading a webpage or doing pretty much anything else online the DNS delay is negligible. And if the answer is already cached in my house it's definitely faster than having to leave my home network to get a response.

Re: Issues with 1.1.1.1 public resolver and WARP

#103

Earlier quoted context omitted.

How slow is running your own recursive DNS?

It's actually a lot faster since unbound can prefetch and cache your most common queries. Most lookups in my pihole resolve in sub 1ms

Yeah but that's the same as a regular home DNS server that isn't recursive. Your devices also have their own cache.

Re: Issues with 1.1.1.1 public resolver and WARP

#104

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…

I was using Cloudflare DNS for a while until learning it was the cause of archive brokenness, switched to Google DNS, and recently have started trying out Adguard DNS just out of curiosity of trying out DNS-over-QUIC (requires a VPN app that supports that). Can't say whether it's better or worse but always fun to try out a new tech.

Re: Issues with 1.1.1.1 public resolver and WARP

#105

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…

Cloudflare is in the wrong here. Archive.is had to develop a unique CDN system to protect against illegal content being uploaded and immediately reported, which led to server seizures and downtime. Cloudflare's DNS disrupts this system, putting archive.is at risk. Archive.is even offered to proxy Cloudflare DNS users via their CDN, but Cloudflare rejected the proposal. This leaves archive.is in a vulnerable position, and it's unreasonable to expect them to register their own autonomous system just to fix this issue.

Re: Issues with 1.1.1.1 public resolver and WARP

#106
post #96

Earlier quoted context omitted.

I would doubt the owner has a bigger network than cloudflare as their cdn. If you're cdn is Azure, GCE, or AWS, than you're cdn is spread over the regions that their cloud offers. You still have no use-case to know more. So, who? There isn't a provider atm in the world. So the issue at hand is currently not existent, as far as I'm aware.

Yeah, so cloudflare is making sure no one else can compete.

Didn't read the last alinea?

> 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.

---

I don't know what happened between that statement and now. Since they were working together with eg. Google to solve it.

Still. No example? So not an issue now?

Re: Issues with 1.1.1.1 public resolver and WARP

#107

Earlier quoted context omitted.

I would doubt the owner has a bigger network than cloudflare as their cdn. If you're cdn is Azure, GCE, or AWS, than you're cdn is spread over the regions that their cloud offers. You still have no use-case to know more. So, who? There isn't a provider atm in the world. So the issue at hand is currently not existent, as far as I'm aware.

Let's say you have more fine-grained capacity in a given metro than Cloudflare has in an attempt to provide additional value in that metro than Cloudflare can offer. You are blocked from doing so if endusers are using Cloudflare DNS. I don't know if this is happening at the moment, but it's pretty clear that there is no real incentive to even attempt this given that you simply will not be able to offer any benefits b…

Who would set up ( or use) a dns that is better in 1 metro in the world? Do you?

The example given doesn't make any sense.

You're just giving an ideological example. Not one that occurs in the real world.

Here is one that actually happens: Using cloudflare DNS to protect privacy is one that occurs in the real world and eg. Apple is using them for exactly that.

But let's repeat:

> 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

#108
post #66

Earlier quoted context omitted.

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 t…

Why not use the root.hints file available for this purpose? https://www.iana.org/domains/root/files

Generally it is already included with most DNS servers, such as BIND.

Re: Issues with 1.1.1.1 public resolver and WARP

#109

Earlier quoted context omitted.

It's actually a lot faster since unbound can prefetch and cache your most common queries. Most lookups in my pihole resolve in sub 1ms

Yeah but that's the same as a regular home DNS server that isn't recursive. Your devices also have their own cache.

The point is that if the TTL is 10mins and you lookup the domain after it expires the regular DNS will go and fetch it, unbound fetches it as soon as it expires and it is already cached

Re: Issues with 1.1.1.1 public resolver and WARP

#110

Earlier quoted context omitted.

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 t…

Why not use the root.hints file available for this purpose? https://www.iana.org/domains/root/files Generally it is already included with most DNS servers, such as BIND.

That is useful for the initial bootstrapping but should be updated or at least validated a few times a year. If package maintainers are updating it a few times a year that works too.
Post reply on HN