Live data from Hacker News

Issues with 1.1.1.1 public resolver and WARP

cloudflarestatus.com

91–100 of 118 posts

Re: Issues with 1.1.1.1 public resolver and WARP

#91

Earlier quoted context omitted.

Thanks for the clarification and link! I do think that this has the effect of locking customers into Cloudflare's geoip data, which seems a little sketchy. The operator of archive.is claims that the data itself is bad[1] but I can't speak to his biases or motivations. If the data is incomplete or bad, then you gain an advantage by using Cloudflare's services over rolling your own or using a competitor if a large numb…

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 because you don't have the data.

Re: Issues with 1.1.1.1 public resolver and WARP

#93
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?

For my DNS resolver I run, it tends to take around twice as long for the initial request compared to other caching resolvers.

Re: Issues with 1.1.1.1 public resolver and WARP

#94

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…

coincidentally archive.ph links started working for me today, so not sure this is true anymore

Re: Issues with 1.1.1.1 public resolver and WARP

#95

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 a "collector of reliable DNS servers"^1 I can report there are DoH servers that will actually take a traditional DNS query that does not support EDNS0 and, perhaps using the client IP from the TCP connection, return a response that includes EDNS0 Client Subnet (ECS). Whether the DoH provider is sending the ECS to authoritative servers I do not know, but to me it is quite sad to see this being returned in the response given I did not request it. Anyway, ECS is supposedly the reason 1.1.1.1 does not include DNS data for archive.is

The site once used a tracking pixel as a poor mans ECS. The client IP address was inserted into the image name. Apparently the operator of the site explained this was used to achieve CDN-like functionality:

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

1. Perhaps we should be clear that "servers" here means open resolvers. These servers are of course not authoritative for any name, and generally recursion is slower than iteration, i.e., use of authoritative servers only (fee free to challenge me on this and I will share a citation, although I know this is true from own experiments). Thus "reliable" is perhaps ambiguous. Not all of them always return the same results. Some will return different answers, and not always for "load balancing" reasons. Some may be missing data entirely. Some will return wrong answers, e.g., pretending to be authoritative. Much DNS funny business on the internet today. I gather results from a variety of resolvers, from authoritative servers as well as other sources of DNS data, e.g., public zone files, scans and crawls, and I compare notes; I personally would not feel comfortable using one open resolver (third party DNS) as the source for all DNS data; I could not rely on it. As such, "reliable" is IMHO a loaded term if used to describe open resolvers.

Re: Issues with 1.1.1.1 public resolver and WARP

#96

Earlier quoted context omitted.

Thanks for the clarification and link! I do think that this has the effect of locking customers into Cloudflare's geoip data, which seems a little sketchy. The operator of archive.is claims that the data itself is bad[1] but I can't speak to his biases or motivations. If the data is incomplete or bad, then you gain an advantage by using Cloudflare's services over rolling your own or using a competitor if a large numb…

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.

Re: Issues with 1.1.1.1 public resolver and WARP

#97
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/

Do you happen to have a mapping of Cloudflare IP space to physical POPs?

To the best of my knowledge they do not publish this, which makes it quite a chore to track all their edge locations manually.

Re: Issues with 1.1.1.1 public resolver and WARP

#98
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?

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

Re: Issues with 1.1.1.1 public resolver and WARP

#99
post #44
post #30

Earlier quoted context omitted.

How come archive.is works for me? I have set up Cloudflare DoH in my router, I block other popular DoH servers on my network and I also redirect any other DNS queries (UDP 53) to my router's DNS (which in turn uses Cloudflare). And at least in my region (EU) I did not notice any issues with 1.1.1.1.

Maybe your computer ignores the DNS resolver address suggested by your router? You can check with dig what resolver you’re using, if you’re on a Unix-like system.

No, I mean - it uses Cloudflare and it works. I did try with dig. :) Also tried it from other countries in EU, works fine.

Re: Issues with 1.1.1.1 public resolver and WARP

#100
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?

I reroute all DNS queries attempting to leave my network to my DNS server. It won't work in scenarios where there is DoH without user consent, however at that point I should reconsider purchasing such hostile devices.
Post reply on HN